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Introduction  and  Overview 

Many  modem  distributed  services,  network  protocols  and  applications  are  deployed  over  insecure  and 
unreliable  public  networks,  such  as  the  global  internet.  Communication  security  is  based  upon  availability 
of  timely,  efficient  and  effective  security  services.  Some  of  the  most  formidable  security  challenges  are 
represented  by  the  high  cost  of  security  and  by  the  insufficiently  controlled  access  to  security  services.  To 
this  end,  this  project  proposed  two  new  directions  in  information  security.  The  first  applied  to  dynamic 
networks  where  security  capabilities  of  end-users  must  be  tightly  controlled.  The  second  applied  to 
networks  containing  low-powered  devices  such  as  PDAs  and  smartcards.  Our  approach  uses  partially 
trusted  security  mediators  and  is  well  suited  for  both  military  and  civilian  applications.  Following  are  the 
highlights  of  the  work: 

•  Tightly  Controlled  Security  Services.  Many  situations  call  for  a  security  officer  to  quickly  revoke, 
reinstate  or  alter  an  end-user’s  ability  to  take  part  in  critical  security  tasks.  We  say  that  a  capability  is 
tightly  controlled  if  it  can  be  quickly  revoked  at  will.  Our  architecture  provides  tight  control  over  the 
following  end-user  capabilities:  (1)  generation  of  digital  signatures,  (2)  decryption  of  messages,  and 
(3)  authentication  to  others.  We  achieve  this  without  relying  on  Certificate  Revocation  Lists  (CRLs) 
and  other  off-line  means.  Instant,  fine-grained  control  of  security  services  is  particularly  useful  in 
battle-field  scenarios.  (For  example,  all  security  capabilities  of  captured  equipment  or  personnel  must 
be  immediately  disabled.)  It  is  also  well-suited  to  civilian  applications  where  activities — such  as 
signing  contracts  and  decrypting  sensitive  data — must  be  both  revocable  and  tightly  controlled. 

We  obtain  tight  control  over  security  capabilities  by  requiring  each  end-user  to  interact  with  an 
untrusted  SEcurity  Mediator  (SEM).  An  end-user  cannot  generate  a  valid  signature  or  decrypt  a 
message  without  the  SEM’s  help.  To  revoke  an  end-user’s  security  capability,  the  security  officer 
simply  instructs  the  SEM  to  refuse  any  interaction  with  the  said  end-user  thereby  attaining  instant 
revocation.  The  mediator  is  carefully  designed  to  minimize  both  interaction  and  computation  so  as  to 
increase  robustness  and  availability.  In  the  same  vein,  SEM  is  physically  distributed  to  facilitate 
scalability,  fault  tolerance  and  minimize  risks  from  denial-of-service  attacks. 

•  Networks  of  Weak  Devices.  In  networks  containing  low-powered  devices  (e.g.,  PDA-s)  security 
operations  often  represent  a  performance  bottleneck.  As  an  outgrowth  of  the  above,  we  offload  heavy 
security  computations  to  an  untrusted  SEM.  We  aim  to  do  so  without  compromising  end-device’s 
secrets  and  by  taking  advantage  of  the  superior  computing  power  of  SEM. 

o  Aided  key  generation.  Generating  cryptographic  keys  on  weak  devices  such  as  PDAs  and 
cell-phones  takes  on  the  order  of  many  minutes:  both  the  delay  and  power  consumption  are  of 
concern.  We  developed  techniques  that  enable  a  weak  device  to  offload  much  of  the  key 
generation  work  to  an  un-trusted  SEM.  This  way,  key  generation  delay  is  reduced  to  a  few 
seconds.  At  the  end  of  the  computation,  the  SEM  has  no  information  about  the  secret  key  it 
helped  generate.  This  kind  of  aided  key  generation  can  be  used  by  smartcards  as  well  as  other 
embedded  devices. 

o  Aided  signature  computation.  Similar  to  the  above,  we  investigated  and  developed  methods 
for  offloading  costly  components  of  public  key  signature  generation  to  untrusted  mediators. 
We  considered  several  methods  for  doing  so.  The  end-device  needs  to  compute  only  a  few 
hashes  per  signature  while  retaining  full  benefits  of  public  key -based  signatures. 

o  We  demonstrated  the  effectiveness  of  our  approach  by  implementing  all  new  techniques  as  a 
library  of  mediated  cryptographic  services.  The  library  implements  both  tight  control 
mechanisms  and  off-loading  of  security  computations.  The  usage  of  wrappers  enabled  easy 
integration  of  our  code  into  existing  projects/products.  This  work  resulted  in  numerous 
insights  into  the  delicate  and  difficult  integration  of  cryptographic  protocols  with  practical 
communication  systems. 

•  Identity  Based  Encryption.  The  complexity  of  managing  public-key  certificates  motivated  Adi  Shamir 
to  propose  the  idea  of  Identity  Based  Encryption  (IBE)  back  in  1984.  Unfortunately  no  usable 
implementations  of  IBE  were  known.  During  the  course  of  this  project,  and  motivated  by  the 
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complexity  of  revoking  certificates,  we  discovered  a  very  practical  1BE  system.  An  IBE  system  is  a  public- 
key  encryption  mechanism  where  public  keys  can  be  arbitrary  strings,  such  as  email  addresses,  phone 
numbers,  or  dates.  At  a  high  level,  IBE  essentially  eliminates  the  need  for  certificates  since  a  person’s 
public-key  is  just  that  person’s  public  identity.  During  the  course  of  the  project  we  successfully 
demonstrated  that  IBE  leads  to  simple  public-key  management.  We  implemented  an  IBE  library  and 
integrated  IBE  with  several  mail  readers.  In  2002  several  of  our  students  launched  a  start-up  company, 
Voltage  Security,  to  commercialize  IBE.  The  company  participated  in  this  year’s  JWID  and  the  resulting 
reviews  are  very  favorable. 

Project  Accomplishments:  Year  1 

As  the  initial  step  in  the  project,  an  extensive  literature  review  has  been  undertaken  in  order  to  locate  any 
current  or  past  research  efforts  with  goals  similar  to  those  of  SUCSES.  A  number  of  activities  were 
identified. 

The  project  Web  page  was  designed  and  advertised  in  several  security-related  conferences  and  Internet 
newsgroups.  It  includes,  among  other  things,  project  goals,  problem  statement,  quad  charts  as  well  as  other 
documents  and  publications. 

Starting  in  mid-August  we  began  working  on  the  initial  architecture  of  the  SUCSES  toolkit.  Basic  layering 
design  has  been  done;  however,  a  low-level  modular  arithmetic  package  has  not  been  selected  yet.  Since 
there  were  a  number  of  public  domain  software  packages,  selecting  the  optimal  one  required  some 
experimentation  with  all. 

The  SAS  component  of  SUCSES  has  undergone  several  revisions.  The  most  recent  version  has  the 
following  features: 

•  Support  for  X.509  certificates 

•  Seamless  migration  of  SEMs 

•  Fully-configurable  interface  and  system  parameters 

•  MOTIF -based  user  interface 

•  Signed  error  messages  from  SEM 

•  Platform  independence  (SUNos,  SOLARIS  and  LINUX) 

•  Documented  API 

The  following  activities  were  started  during  the  first  year  of  the  project  and  completed  in  later  years: 

•  SAS  plug-in  for  Netscape  Communicator 

•  Measurements  for  SAS  versus  plain-RSA  overhead 

•  Integration  (unification)  with  Stanford's  communication  platform 

One  of  our  main  goals  was  to  off-load  expensive  part  of  generating  RSA  keys  on  a  handheld  device  such  as 
the  PalmPilot.  Our  prototype  showed  how  to  speed  up  RSA  key  generation  by  a  factor  of  six  without 
compromising  the  security  of  the  generated  key.  We  obtained  this  speedup  by  offloading  most  of  the  key 
generation  work  onto  an  untrusted  server.  The  server  did  most  of  the  work,  but  learned  nothing  about  the 
key  it  helped  generate. 

During  the  past  year  we  extended  our  RSA  server  aided  architecture  to  also  support  RSA  signature 
generation.  The  resulting  prototype  can  be  used  for  both  RSA  key  generation  and  RSA  signature 
generation.  We  use  the  PalmPilot  as  an  example  handheld  device.  We  chose  the  PalmPilot  since  it  is  easy 
to  program  and  to  experiment  with. 

When  using  1024  bit  RSA  keys  our  new  prototype  implementation  shows  that  RSA  signature  generation 
can  be  sped  up  by  a  factor  of  2.5.  We  used  a  500  MHz  Pentium  III  as  the  server.  The  implemented 


2 


protocol  is  based  on  new  practical  techniques  for  generating  RSA  signatures  with  the  help  of  an  untrusted 
server.  Both  results  on  RSA  key  generation  and  RSA  signatures  were  reported  in  the  technical  literature. 

Our  primary  research  result  this  year  is  the  novel  scheme  for  mediated  (SEM-assisted)  RSA  signatures  and 
RSA  decryption.  Mediated  RSA  (MRSA)  is  different  from  SAS  in  that  the  actual  MRSA  signature  is 
indistinguishable  from  a  plain  RSA  signature.  The  approach  can  be  roughly  outlined  as  follows: 

Setup: 

1 .  CA  generates  a  number  of  half-RSA  keys,  one  for  each  SEM. 

2.  CA  assigns  to  each  client  (user)  is  assigned  a  half-RSA  key  as  well. 

Signature: 

1 .  When  client  requests  an  RSA  signature,  he  sends  the  text  to  SEM 

2.  If  client  is  not  revoked,  SEM  computes  a  half- signature  with  its  key  and  returns  the  result 

3.  Client  proceeds  to  use  his  half-key  to  obtain  an  actual  RSA  signature  (which  he  also  verifies!) 
Mediated  decryption  works  in  a  similar  manner. 

The  interesting  security  properties  are:  1)  no  communication  between  CA  and  SEM;  2)  Computational 
overhead  only  double  of  plain  RSA;  3)  Verification  unchanged  from  plain  RSA;  4)  No  certificates  for 
SEMs  (we  use  id-based  assignment  of  half-keys;  see  below);  5)  No  per-user  state  on  the  SEM;  6)  SEM 
knows  no  user  secrets,  cannot  impersonate  users; 

The  initial  (proof-of-concept)  implementation  of  MRSA  is  taking  place  over  the  summer.  We  conducted 
extensive  measurements  of  its  effectiveness  and  costs. 

One  important  goal  of  the  SUCSES  project  is  to  show  how  a  SEcurity  Mediator  (SEM)  can  be  used  for  key 
management  and  key  revocation.  During  this  first  year  we  added  another  feature  to  the  SEM  design: 
identity-based  encryption. 

Identity-based  encryption  considerably  simplifies  certificate  management.  Currently,  when  Alice  wants  to 
send  a  message  to  Bob  she  must  first  obtain  Bob's  public  key  certificate.  When  using  identity-based 
encryption,  Bob's  public  key  is  simply  Bob's  Email  address.  Hence,  Alice  need  not  obtain  Bob's  certificate. 
She  simply  encrypts  using  Bob's  Email  address  as  a  public  key.  Bob  obtains  the  private  key  corresponding 
to  his  Email  address  from  the  CA.  Unfortunately,  there  are  yet  no  usable  public  key  systems  that  support 
identity-based  encryption.  However,  as  is  turns  out,  RSA  can  be  easily  converted  into  an  identity-based 
system  by  using  an  untrusted  SEM.  All  encrypted  Email  flows  through  the  SEM.  The  SEM  gains  no 
information  about  the  contents  of  the  encrypted  Email  it  is  handling.  As  encrypted  Email  flows  through  the 
SEM,  the  SEM  applies  a  certain  simple  operation  to  the  Email  header.  The  recipient  then  decrypts  the 
message  using  his  private  key. 

Project  Accomplishments:  Year  2 

We  briefly  recall  the  objective  of  the  SUCSES  project:  to  develop  novel  technologies  for  survivable 
security  services.  The  main  goal  is  to  provide  organizations  (military  and  civilian)  with  tight  control — as 
opposed  to  today’s  certificate-based  loose  control — over  end-users’  security  privileges  such  as  digital 
signatures  and  data  encryption/decryption.  At  the  same  time,  SUCSES  aims  to  greatly  simplify  public  key 
certificate  management  by  developing  novel  techniques  that  do  not  require  the  use  of  certificates.  An 
additional  goal  is  to  assist  weak  computing  devices  (e.g.,  PDAs)  by  providing  them  with  the  same  full 
security  functionality  (digital  signatures,  public  key  encryption,  key  generation)  that  is  available  for  more 
powerful  devices  while  retaining  the  ability  to  instantly  revoke  a  device’s  access  to  security  services. 

The  centerpiece  of  the  SUCSES  project  is  a  component  called  Security  Mediator  (SEM).  SEM  is  an  on-line 
entity  charged  with  assisting  end-users  (and  end-devices)  in  obtaining  security  services.  By  mediating 
access  to  critical  security  services,  a  SEM  acts  both  as  a  helper  and  an  on-line  revocation  authority.  Also,  in 
the  process  of  assisting  end-users  (specifically  weak  devices)  SEM  off-loads  from  them  some  of  the 
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computational  and  storage  burden  involved  in  costly  cryptographic  operations.  At  the  same  time,  an  SEM  is 
not  entrusted  with  end-users’  secrets  and  cannot  impersonate  and/or  cheat  constituent  end-users  without 
detection. 

Using  SEM-based  mediation  requires  careful  division  of  labor  between  the  traditional  role  of  an  off-line 
Certification  Authority  (CA)  and  the  on-line  SEMs.  Interactions  between  SEMs  and  end-users  are  kept  to  a 
minimum  so  as  to  make  the  SEM  as  unobtrusive  as  possible.  Protocols  between  SEM  and  end-user  are 
designed  to  be  both  provably  secure  and  fault-tolerant. 

Generating  strong  cryptographic  keys  on  small  devices  such  as  a  PalmPilot  takes  considerable  time  (tens 
of  minutes).  SUCSES  is  developing  techniques  to  enable  such  devices  to  offload  much  of  the  public  key 
generation  work  to  an  untrusted  SEM.  However,  at  the  end  of  the  computation,  SEM  has  no  information 
about  the  secret  key  it  helped  to  generate.  This  way,  key  generation  delay  can  be  reduced  to  a  few  seconds. 
Aided  key  generation  of  this  type  can  be  used  by  smartcards  as  well  as  other  embedded  devices.  In  the 
same  vein,  investigation  and  development  of  methods  for  offloading  costly  components  of  public  key 
signature  generation  to  untrusted  mediators  will  be  undertaken.  Several  methods  will  be  considered. 
Ideally,  the  end-device  will  need  to  compute  only  a  few  inexpensive  hashes  per  signature  while  retaining 
full  benefits  of  public  key-based  signatures. 


ACCOMPLISHMENTS: 

Most  public  key  methods  are  based  on  a  binding  between  users  and  their  respective  keys.  Such  bindings 
are  usually  expressed  in  certificates;  this  requires  complex  means  of  issuance,  distribution  and  revocation. 
In  contrast,  identity-based  encryption  considerably  simplifies  certificate  management.  Currently,  when 
Alice  wants  to  send  a  message  to  Bob  she  must  first  obtain  Bob’s  public  key  certificate.  With  identity- 
based  encryption,  Bob’s  public  key  is  simply  Bob’s  Email  address.  Hence,  Alice  need  not  obtain  Bob’s 
certificate.  She  simply  encrypts  using  Bob’s  Email  address  as  a  public  key.  Bob  obtains  the  private  key 
corresponding  to  his  Email  address  from  the  CA. 

During  the  past  year  a  new  identity-based  encryption  scheme  (IBE)  has  been  developed.  It  is  based  on  the 
concept  of  “Weil  Pairing”  on  elliptic  curves.  Unlike  SAS  and  mRSA,  IBE  requires  no  on-line  interaction. 
IBE  greatly  simplifies  public  key  certificate  management  since,  in  it,  a  user’s  public  key  can  be  derived 
from  a  unique  identifier,  such  as  an  email  address.  IBE  is  not  only  a  practical  scheme,  it  also  addresses 
what  has  been,  for  a  long  time,  an  important  open  problem  in  cryptography.  IBE  can  also  be  used  in  order 
to  perform  secure  delegation  of  cryptographic  keys  to  untrusted  or  partially  trusted  devices. 

The  SAS,  mRSA  and  IBE  components  of  SUCSES  have  been  fully  implemented  as  public  domain 
libraries  and  email  plug-ins.  The  following  software  has  been  developed  in  the  past  year  (all  components 
are  available  for  download  from  the  SUCSES  web  page): 

•  mRSA  and  SAS  client  libraries 

•  IBE  libraries 

•  IBE  plug-in  for  Eudora 

•  SAS  signature  verification  program  for  Netscape  and  Outlook 

•  SAS  plug-in  for  Eudora 

•  mRSA  plug-in  for  Eudora  (Netscape  and  Outlook  require  no  changes  to  verify  mRSA  signatures) 

•  Stand-alone  Unix-based  SEM  daemon  supporting  both  SAS  and  mRSA 

•  A  collection  of  CA  utilities  for  certificate  management 

Extensive  performance  tests  of  the  software  have  been  undertaken.  The  results  clearly  indicate  that,  for 
small  devices,  SAS  performs  significantly  better  than  plain  RSA  when  a  SEM  is  located  on  the  same  LAN 
or  campus  network.  (The  performance  of  SAS  degrades  as  the  client-SEM  distance  grows.)  mRSA  tests 
demonstrate  performance  that  is,  on  the  average,  3-4  times  worse  than  plain  RSA.  However,  for  interactive 
applications  (such  as  email),  the  slowdown  is  not  noticeable. 

Experiments  using  an  unoptimized  version  of  the  IBE  system  shows  that  encryption/decryption  take  about 
0.3  seconds  on  an  800  MHz  PHI.  Hence,  even  an  unoptimized  version  of  the  system  is  quite  practical.  We 
are  currently  optimizing  the  IBE  library  and  hope  to  reduce  the  time  for  encryption/decryption  to  under  0.1 
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seconds.  Other  projects  are  welcome  to  use  the  implementation  of  the  IBE  system.  The  IBE  library  is  open 
source. 


Planned  Technology  Transition 

Technical  transfer  discussions  with  Rainbow  Technologies,  ENTRUST,  Microsoft  and  Verisign  were  held 
throughout  the  past  year.  Some  of  these  contacts  are  still  on-going,  while  others  (Entrust  and  Rainbow) 
terminated  because  of  the  worsened  economy  in  early  2001.  Both  Verisign  and  Microsoft  were  happy  to 
learn  about  the  capabilities  of  mRSA  and  its  application  to  code  signing.  Last  year,  Verisign  made  a  costly 
blunder  when  it  issued  a  Microsoft  code  signing  certificate  to  an  unknown  person.  This  mishap  clearly 
illustrated  the  difficulty  of  revocation  with  current  methods.  As  a  result,  both  Verisign  and  Microsoft  are 
interested  in  fast  revocation  technologies  for  code  signing  certificates.  mRSA  provides  easy  revocation 
compatible  with  today’s  deployed  software. 


The  intent  is  to  deploy  both  IBE  and  mRSA/SAS  on  the  global  Internet.  To  this  end,  a  “secure”  web  site  is 
being  built  to  store  the  IBE  root  keys.  Initially,  this  site  will  be  hosted  in  a  physically  secured  location  at 
Stanford  campus.  As  mentioned  above,  full  deployment  is  expected  to  take  place  before  the  end  of  the  year 


Project  Accomplishments:  Year  3 

We  developed  an  open-source  library  implementing  the  new  Identity  Based  Encryption  scheme  (IBE). 
Most  of  the  effort  went  into  optimizing  the  library  for  performance.  Encryption  and  decryption  now  take 
40ms  on  a  lGhZ  Pentium  III.  The  library  is  open  source  and  is  available  for  download  at 
http://crvpto.stanford.edu/ibe 

We  also  prototyped  an  identity-based  email  system.  This  is  part  of  a  larger  project  for  building  an  identity- 
based  PKI.  The  email  system  supports  Outlook,  Eudora,  Hotmail,  and  Yahoo  mail.  The  system  was 
deployed  in  year  3  and  currently  has  approximately  200  regular  users  world  wide. 

The  same  crypto  technology  that  made  the  new  IBE  system  possible  can  also  be  used  to  provide  very  short 
digital  signatures.  These  signatures  are  half  the  size  of  DSS  signatures  and  provide  the  same  level  of 
security.  Our  short  signature  scheme  has  been  implemented  and  is  available  for  download  along  with  the 
library  implementing  IBE.  An  interesting  property  of  the  signature  scheme  is  that  its  performance  is  the 
reverse  of  the  performance  of  RSA  signatures:  signature  generation  is  fast  where  as  signature  verification  is 
slow  (signature  generation  is  three  times  faster  than  RSA  signature  generation  and  the  signature  is  about 
one  tenth  the  size)  Hence,  this  signature  scheme  is  better  suited  than  RSA  for  handheld  devices  that 
generate  signatures. 

An  ID-based  variant  of  mRSA  (IB-mRSA)  has  been  designed  and  implemented.  IB-mRSA  is  a  simple  and 
practical  identity-based  signature  and  encryption  method.  Its  main  difference  from  mRSA  is  the  use  of 
identities  in  computing  users’  public  keys.  It  is  fully  compatible  with  mRSA  and  plain  RSA.  Its 
performance  (for  data  encryption  and  verification  of  signatures)  is  only  slightly  lower  than  that  of  mRSA.  It 
offers  a  realistic  transition  scenario  for  gradual  introduction  of  public  key  cryptography.  Moreover,  it 
combines  the  reduced  reliance  on  certificates  (common  to  all  ID-based  schemes)  with  the  fine-grained 
revocation  intrinsic  to  mRSA. 

A  forward-secure  variant  of  mRSA  (FS-mRSA)  has  also  been  designed  and  implemented.  FS-mRSA 
provides  extra  security  over  mRSA  by  periodically  evolving  the  user’s  private  key.  Consequently,  even  if 
the  adversary  compromises  the  user’s  secrets,  he  is  unable  to  forge  user’s  signatures  rooted  in  the  past. 
Furthermore,  FS-mRSA  supports  the  notion  of  “expiring  encryption”  whereby  data  encrypted  for  the  user 
can  be  made  valid  up  to  a  certain  time.  Thereafter,  even  the  legitimate  user  cannot  decrypt  the  data.  Also, 
the  adversary  who  eavesdrops  on  encrypted  data  and  later  compromises  the  user’s  secrets  is  unable  to 
decrypt  pre-recorded  data.  Finally,  the  added  forward  security  feature  in  FS-mRSA  does  not  degrade  the 
performance  (i.e.,  it  is  as  efficient  as  normal  mRSA). 
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The  currently  available  software  includes  the  following  components  (note  that  all  components  are  available 
for  download  from  the  SUCSES  web  page): 

•  mRSA,  SAS,  FS-mRSA  and  IB-mRSA  client  libraries 

•  Microsoft  Outlook  and  Eudora  plug-ins  for  mRSA,  FS-mRSA  and  IB-mRSA  signatures 

•  Decryption  helpers  for  mRSA,  FS-mRSA  and  IB-mRSA  encrypted  messages  (work  withe  MS 
Outlook,  Eudora  and  Netscape  Messenger) 

•  A  stand-alone  email  proxy  (instead  of  plug-ins)  supporting  SAS  and  mRSA  signatures 

•  Stand-alone  Unix-based  SEM  daemon  supporting  both  SAS  and  mRSA 

•  A  collection  of  CA  utilities  for  certificate  management 

•  Optimized  IBE  crypto  library  including  support  for  short  signatures 

•  Microsoft  Outlook,  Hotmail,  Yahoo  mail,  Eudora,  and  Pine  plug-ins  for  the  IBE  email  system 

•  Key  generation  and  user  management  system  to  be  used  with  the  IBE  mail  plug-ins 


Technical  contacts  are  still  being  maintained  with  Microsoft  and  Verisign  regarding  possible  technology 
transfer  venues. 

Project  Accomplishments:  Year  4 

One  of  the  main  research  contributions  of  SUCSES  has  been  the  invention  of  a  practical  identity-based 
public  key  cryptosystem  (IBE).  IBE  allows  us,  among  other  things,  to  build  an  Email  system  where  a  party 
A  can  send  secure  Email  to  party  B,  even  if  the  latter  has  no  public  key  yet.  The  IBE  system  is 
implemented  and  accessible  via  an  easy-to-use  plug-in  for  common  mail  readers  such  as  Outlook  and  pine. 
The  resulting  system  makes  it  very  simple  for  people  to  communicate  securely  via  email.  A  technical  paper 
describing  the  identity-based  encryption  system  (based  on  Weil  Pairing)  was  presented  in  Crypto  2001. 

The  IBE  implementation  is  now  fully  optimized:  it  takes  about  30ms  for  encryption  &  decryption  on  a  1- 
GHz  Pentium.  Hence  the  system  is  fast  enough  to  replace  RSA  in  commercial  applications.  The 
implementation  is  open  source  and  is  available  on  the  project’s  web  site. 

We  completed  a  mail  gateway  for  Windows  for  performing  IBE  e-mail  encryption  on  the  fly.  The  mail 
gateway  enables  us  to  encrypt/decrypt  any  e-mail  sent  from  any  Windows  mail  reader.  The  resulting 
system  is  a  brand  new  approach  for  dealing  with  secure  e-mail.  We  are  hoping  it  will  spread  through  the 
population  in  a  viral-like  effect  (Alice  sends  secure  mail  to  Bob  causing  Bob  to  send  secure  mail  to  Carol 
and  so  on). 

We  also  deployed  IBE  email  for  world-wide  use  using  Internet  Explorer  plug-ins  for  hotmail  and  Yahoo! 
mail.  The  Private  Key  Generator  (PKG)  is  running  at  Stanford.  We  are  currently  tracking  the  adoption 
rate. 


IBE-Related  Results 

The  techniques  we  used  to  construct  our  IBE  cryptosystem  can  be  used  to  solve  many  open  problems  in 
cryptography.  We  give  three  examples  that  we  believe  are  the  most  exciting  (the  second  application  is  new 
for  this  reporting  period). 

Short  digital  signatures.  Using  the  principles  underlying  our  IBE  system  (the  Weil  pairing)  we  were  able 
to  construct  a  signature  scheme  where  the  signatures  are  very  short.  Signatures  in  our  scheme  provide  the 
same  security  as  DSS  signatures,  but  are  half  the  size.  Such  short  signatures  are  important  for  bandwidth 
constrained  applications  and  especially  applications  where  a  human  is  asked  to  type  in  a  digital  signature. 
This  often  comes  up  in  software  product  activation  mechanisms  where  a  user  types  in  a  digital  signature  to 
unlock  the  software  product. 

Aggregate  signatures.  Surprisingly,  the  short  signature  scheme  described  above  has  some  unexpected 
properties  -  it  supports  signature  aggregation.  Signature  aggregation  enables  anyone  to  compress  a  list  of 
signatures  on  different  messages  generate  by  many  users  into  a  single  signature.  This  is  useful,  for 
example,  for  shortening  certificate  chains.  Recall  that  a  certificate  chain  of  depth  n  contains  n  signatures 
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issued  by  each  of  the  n  Certificate  Authorities.  Aggregate  signatures  enable  all  these  signatures  to  be 
aggregated  into  a  single  signature,  thus  shortening  the  certificate  chain.  Aggregate  signature  can  also  be 
used  to  reduce  the  bandwidth  in  secure  routing  protocols  such  as  SBGP. 

Public  key  searching  on  encrypted  data.  Suppose  Alice  sends  Bob  an  encrypted  email  containing  the 
keyword  “Urgent”.  Bob  would  like  his  mail  gateway  to  forward  such  email  to  Bob’s  pager.  Unfortunately, 
with  encrypted  email  the  gateway  cannot  tell  that  the  email  contains  the  word  “Urgent”.  Using  our  IBE 
mechanism  we  are  able  to  build  an  email  system  in  which  Bob  can  give  the  mail  gateway  a  key  that  enables 
the  gateway  to  test  whether  the  email  contains  the  “Urgent”  keyword,  but  the  gateway  learns  nothing  else 
about  the  email.  An  observer,  who  does  not  have  the  key,  learns  absolutely  nothing  about  the  email 
contents  (other  than  the  length  of  the  email). 


Other  Accomplishments 

In  prior  reports,  we  have  described  the  SAS,  mRSA  and  ID-mRSA  components  of  the  SUCSES  project. 
We  have  completed  the  implementation  (client  libraries,  SEM  support,  CA  utilities  and  Eudora/Outlook 
plug-ins)  of  SAS,  mRSA  and  ID-mRSA  functions.  During  this  reporting  period,  our  development  efforts 
concentrated  mainly  on  developing  installation  packages  and  documentation  for  both  MS  Outlook™  and 
Eudora™  plug-ins. 

The  work  on  mediated  Diffie-Hellman  key  exchange  (mDH)  is  still  in  progress.  Subsequent  plans  include 
integration  of  mDH  with  the  popular  Kerberos  Authentication  Service.  In  addition,  we  are  working  on  a 
version  of  mRSA  that  supports  so-called  blind  signatures.  Such  signatures  are  useful  in  environments 
where  the  SEM  must  be  prevented  from  identifying  particular  messages  signed  on  behalf  of  a  client.  Note 
that  this  does  not  contradict  the  revocation  functionality  of  a  SEM:  a  SEM  can  identify  the  requesting  client 
and  perform  a  real-time  revocation  check.  However,  a  SEM  is  unable  to  (later)  associate  a  signature  with  a 
particular  signature  request. 

We  have  begun  limited  experimentation  on  the  UCI  campus  with  the  above  software  components.  Practical 
experience  gained  from  using  our  implementation  will  be  valuable  in  identifying  usability  issues  and 
comparing  our  revocation  approach  with  the  traditional  CRL-based  techniques. 


Technology  Transfer 

Voltage  Security,  a  2-year  old  start-up,  is  commercializing  the  IBE  system  developed  in  the  course  of  the 
project.  The  company  participated  in  this  year’s  JWID  and  received  very  favorable  reviews.  The  Voltage 
product  provides  backend  identity  management  and  frontend  encrypted  email  and  encrypted  files.  There  is 
also  an  available  IBE  toolkit  that  companies  can  use  to  incorporate  IBE  into  their  products.  Recently, 
GemPlus  released  an  implementation  of  our  IBE  system  on  a  GemPlus  smartcard.  The  combined 
SAS/mRSA/IB-mRSA  is  being  phased  in  for  use  at  UCI  ICS  Department. 

Conclusion 

The  SUCSES  project  has  made  fundamental  contributions  to  the  science  and  engineering  of  secure 
communications  in  a  packet-switched  network  such  as  the  Internet.  Three  broad  areas  of  research  were 
addressed  in  the  project:  control  of  security  services,  security  in  networks  of  low-performance  devices,  and 
identity-based  encryption. 

The  project  developed  strong  theoretical  and  practical  results  in  the  fine-grain  control  of  security  services, 
especially  in  group  signatures  and  immediate  revocation.  The  work  resulted  in  a  comprehensive  study  of 
how  to  implement  safe,  fast  revocation  of  certificates  and  security  capabilities  on  large  networks.  The 
architecture  developed  and  demonstrated  relies  on  the  SEM  security  mediator,  a  distributed  and  highly 
scalable  approach  to  tight  security  control.  It  has  been  shown  to  be  resilient  and  highly  robust  against 
distributed  denial-of-service  attacks. 

The  project  was  one  of  the  first  to  recognize  the  need  for  fresh  approaches  to  enabling  security  in  networks 
of  marginally  capable  devices,  such  as  cell  phones  and  personal  digital  assistants.  The  problems  of 
efficiently  generating  RSA  keys  on  low-power  handheld  devices  were  highlighted  and  innovatively  solved 
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in  the  project.  This  subfield  has  gone  on  to  become  a  very  active  area  of  research  in  security.  Of  particular 
interest  is  the  technique  aiding  weaker  devices  by  allowing  a  more-powerful  server  to  assist  in  the 
processing  of  information  used  in  key  generation  and  signature  computation. 

Finally,  the  pioneering  work  in  identity-based  encryption,  where  public  keys  can  take  on  human-friendly 
formats  (e.g.  string  names)  rather  than  machine-oriented  formats  (e.g.  abstract  numbers).  Building  on 
suggestions  made  two  decades  ago  but  never  pursued,  the  project  developed,  validated,  and  demonstrated 
actual  1BE  concepts  that  were  incorporated  in  a  prototype  and  picked  up  for  commercialization  by  Voltage 
Security,  Inc.  The  IBE  system  is  operational  in  several  installations,  providing  effective,  easy-to-use 
public-key  services  to  a  growing  community  of  users. 

The  SUCSES  project  has  cut  a  wide  swath  during  its  period  of  performance,  producing  significant  findings 
of  broad  applicability  in  privacy  and  security  of  networked  and  distributed  systems.  The  results  have 
seeded  research  in  other  related  areas  and  have  been  adopted  by  the  market  for  real  products. 


Project  Personnel 


Name 

Title 

Period  of  performance 

Gene  Tsudik 

Project  Leader  ISI  &  UCI 

throughout 

Joseph  Bannister 

Project  Leader  USC/ISI 

Sept  01  --  Sept  03 

Dan  Boneh 

Project  Leader  Stanford 

throughout 

Xuhua  Ding 

Graduate  Researcher 

Sept  99  -  Sept  03 

Paolo  Montini 

Visiting  Student 

Jan  00  -  July  00 

Kemal  Bicakci 

Graduate  Researcher 

Sept  99  --  July  00 

Ben  Lynn 

Graduate  Researcher 

Sept  00  --  Sept  03 

Hovav  Shacham 

Graduate  Researcher 

Sept  00  --  Sept  03 

Table  1:  Project  Personnel 


Publications 

Following  are  all  project-related  publications  that  appeared  at  refereed  conferences/workshops  and 
archival-quality  journals: 

1.  Leak- free  Group  Signatures  with  Immediate  Revocation,  X.  Ding  and  G.  Tsudik  and  S.  Xu,  24th 
International  Conference  on  Distributed  Computing  Systems  (ICDCS'04),  2004 

2.  Fine-grained  Control  of  Security  Capabilities,  D.  Boneh  and  X.  Ding  and  G.  Tsudik  ,  ACM 
Transactions  on  Internet  Technology,  2004 

3.  Simple  Identity-Based  Encryption  with  Mediated  RSA,  X.  Ding  and  G.  Tsudik,  RSA  Conference, 
Cryptographer's  Track,  2003 

4.  Identity-based  Mediated  RSA,  D.  Boneh,  X.  Ding,  G.  Tsudik,  International  Workshop  on 
Information  and  Security  Applications  (WISA),  2002 

5.  Experimenting  with  Server-Aided  Signatures,  X.  Ding,  G.  Tsudik  and  D.  Mazzocchi,  Network  and 
Distributed  System  Security  Symposium,  2002 

6.  A  Method  for  Fast  Revocation  of  Public  Key  Certificates  and  Security  Capabilities,  D.  Boneh,  X. 
Ding,  G.  Tsudik  and  M.  Wong,  10th  Usenix  Security  Symposium,  Washington  D.C.,  2001 

7.  Generating  RSA  Keys  on  a  Handheld  Using  an  Untrusted  Server,  N.  Modadugu,  D.  Boneh,  and 
M.  Kim,  RSA  Conference,  Cryptographer's  Track,  2000 

8.  Server-Supported  Signatures,  N.  Asokan,  G.  Tsudik  and  M.  Waidner,  Journal  of  Computer 
Security,  November  1997 


9.  How  to  construct  optimal  one-time  signatures,  K.  Bicakci,  G.  Tsudik  and  B.  Tung,  Computer 
Networks  (Elsevier),  Vol  43  (3),  pp.  339-349,  October  2003 

10.  On  constructing  optimal  one-time  signatures,  K.  Bicakci,  G.  Tsudik  and  B.  Tung,  15th 
International  Symposium  on  Computer  and  Information  Sciences,  October  2000 

11.  Weak  Forward  Security  in  Mediated  RSA,  G.  Tsudik,  2002  Security  in  Computer  Networks 
Conference  (SCN'02),  September  2002 

12.  Short  signatures  from  the  Weil  pairing,  D.  Boneh,  H.  Shacham,  and  B.  Lynn,  J.  of  Cryptology, 

Vol.  17,  No.  4,  pp.  297-319,  2004 

Extended  abstract  in  proceedings  of  Asiacrypt  '01,  LNCS  Vol.  2248,  Springer- Verlag, 
pp.  514-532,  2001 

13.  Identity  based  encryption  from  the  Weil  pairing,  D.  Boneh  and  M.  Franklin,  SIAM  J.  of 
Computing,  Vol.  32,  No.  3,  pp.  586-615,  2003. 

Extended  abstract  in  proceedings  of  Crypto  '2001,  Lecture  Notes  in  Computer  Science,  Vol.  2139, 
Springer- Verlag,  pp.  213-229,  2001 

14.  Aggregate  and  Verifiably  Encrypted  Signatures  from  Bilinear  Maps,  D.  Boneh,  C.  Gentry, 

H.  Shacham,  and  B.  Lynn,  proceedings  of  Eurocrypt  2003,  LNCS  2656,  pp.  416-432,  2003 

15.  Short  Signatures  Without  Random  Oracles,  D.  Boneh  and  X.  Boyen, 
proceedings  of  Eurocrypt  2004,  LNCS  3027,  pp.  56-73,  2004 

16.  Public  key  encryption  with  keyword  search, 

D.  Boneh,  G.  Di  Crescenzo,  R.  Ostrovsky,  and  G.  Persiano, 
proceedings  of  Eurocrypt  2004,  LNCS  3027,  pp.  506-522,  2004 

17.  A  Secure  Signature  Scheme  from  Bilinear  Maps,  D.  Boneh,  Ilya  Mironov  and  Victor  Shoup, 
proceedings  of  RSA-CT  '03 


Dissertations  and  theses: 

•  Xuhua  Ding,  Fine-Grained  Control  to  Security  Services,  Ph.D.  Thesis,  Computer  Science 
Department,  University  of  Southern  California,  December  2003 

In  addition,  a  number  of  presentations  were  made  throughout  the  course  of  the  project.  Most  are  listed 
below: 

1.  Invited  Keynote:  Survivability  Using  Controlled  Security  Services,  Workshop  on  Information 
Security  Applications  (WISA'01),  Seoul  (Korea),  September  2001 

2.  Invited  Talk:  Survivable  Security,  Joint  US/EU  Information  Survivability  Workshop,  Malvern, 
UK,  June  2000 

3.  Invited  Distinguished  Lecture:  Controlling  Access  to  Security  Services,  Harvey  Mudd  College, 
January  2001 

4.  JHU-ISI  Distinguished  Lecture  Series:  Fast  Revocation  of  Credentials,  Johns  Hopkins 
University,  October  2001 

5.  UMd-ISR  Distinguished  Lecture:  SUCSES:  Survivability  Using  Controlled  Security  Services, 
University  of  Maryland,  College  Park,  October  2001 

6.  Invited  Talk:  Fast  Credentials  Revocation,  Electronics  and  Telecom  Research  Institute  (ETRI) 
Korea,  September  2001 

7.  Invited  Talk:  Identity-Based  Cryptography,  PKNU  Busan  (Korea),  August  2002 

8.  DTC  Guest  Lecture:  Mediated  Cryptography,  University  of  Minnesota,  February  2003 

9.  Invited  Talk:  RSA  Conference,  Feb.  2003 
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Awards 


•  At  the  DC  PI  meeting  held  in  San  Antonio  in  January  2002,  the  Pis  Dan  Boneh  and  Gene  Tsudik 
were  recognized  for  their  research  in  the  context  of  the  SUCSES  project  with  DARPA  Dynamic 
Coalitions  Program  Award  for  Excellence  in  Academic  Research. 

•  Dan  Boneh  and  Matt  Franklin  received  the  InfoWorld  Innovators  award  on  May  24th,  2004  for 
the  development  of  the  Boneh-Franklin  IBE  system. 


Software 

The  software  developed  in  the  course  of  the  SUCSES  project  is  (and  always  has  been)  publicly  available 
from  the  SUCSES  web  site:  http://sconce.ics.uci.edu/sucses  as  well  as  from  the  companion  site  at  Stanford: 
http://crtvpto.stanford.edu. 


Deployment  and  Technology  Transfer 

Voltage  Security,  a  2-year  old  start-up,  is  commercializing  the  IBE  system  developed  in  the  course  of  the 
project.  The  company  participated  in  this  year’s  JWID  and  received  very  favorable  reviews.  The  Voltage 
product  provides  backend  identity  management  and  frontend  encrypted  email  and  encrypted  files.  There  is 
also  an  available  IBE  toolkit  that  companies  can  use  to  incorporate  IBE  into  their  products.  Recently, 
GemPlus  released  an  implementation  of  our  IBE  system  on  a  GemPlus  smartcard 

The  SEM  toolkit  is  (or  has  been)  in  use  at  NAI  Labs,  UC  Irvine,  Dartmouth,  UIUC,  SRI,  USC/ISI  and 
Stanford. 
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Leak-free  Group  Signatures  with  Immediate  Revocation 


Xuhua  Ding*  Gene  Tsudik 

School  of  Information  Systems  Department  of  Computer  Science 

Singapore  Management  University  University  of  California,  Irvine 

xhding  @smu.edu.sg  gts@ics.uci.edu 

Shouhuai  Xu^ 

Department  of  Computer  Science 
University  of  Texas  at  San  Antonio 
shxu@cs.utsa.edu 


Abstract 

Group  signatures  are  an  interesting  and  appealing  cryp¬ 
tographic  construct  with  many  promising  potential  applica¬ 
tions.  This  work  is  motivated  by  attractive  features  of  group 
signatures,  particularly,  their  potential  to  serve  as  founda¬ 
tion  for  anonymous  credential  systems.  We  re-examine  the 
entire  notion  of  group  signatures  from  a  systems  perspective 
and  identify  two  new  security  requirements:  leak-freedom 
and  immediate-revocation,  which  are  crucial  for  a  large 
class  of  applications.  We  then  present  a  new  group  sig¬ 
nature  scheme  that  achieves  all  identified  properties.  Our 
scheme  is  based  on  the  so-called  systems  architecture  ap¬ 
proach.  It  is  more  efficient  than  the  state-of-the-art  and  fa¬ 
cilitates  easy  implementation.  Moreover,  it  reflects  the  well- 
known  separation-of-duty  principle.  Another  benefit  of  our 
scheme  is  the  obviated  reliance  on  underlying  anonymous 
communication  channels,  which  are  necessary  in  previous 
schemes. 


1.  Introduction 

The  concept  of  group  signatures  was  introduced  by 
Chaum  and  van  Heyst  [18]  in  1991.  The  chief  motiva¬ 
tion  was  to  facilitate  anonymous  group-oriented  appli¬ 
cations.  Given  a  valid  group  signature,  any  verifier  can 
determine  the  signer’s  group  membership,  while  only  a  des¬ 
ignated  entity  (called  a  group  manager)  can  identify  the  ac¬ 
tual  signer.  In  recent  years,  many  research  efforts  sought 
efficient  constructs  and  precise  definitions  of  group  sig¬ 
natures.  Early  schemes  (e.g.,  [19])  suffered  from  lin- 


*  Work  done  at  the  University  of  California,  Irvine, 
f  Work  done,  in  part,  at  the  University  of  California,  Irvine. 


ear  complexities  of  either  (or  both)  group  public  key  size 
or  signature  size  with  respect  to  the  number  of  group  mem¬ 
bers.  These  drawbacks  were  first  addressed  by  Camenisch 
and  Stadler  [13].  Follow-on  results  [12,  1]  gradually  im¬ 
prove  on  efficiency.  Despite  these  advances,  membership 
revocation  remained  a  difficult  obstacle  [7,  33,  2].  Signif¬ 
icant  progress  was  made  by  Camenisch  and  Lysianskaya 
[9]  who  utilized  a  novel  dynamic  accumulator  to  con¬ 
struct  a  group  signature  scheme  with  reasonably  efficient 
revocation.  Further  improvements  have  been  made  re¬ 
cently  by  Tsudik  and  Xu  [34]. 

In  the  past,  group  signature  schemes  aimed  to  sat¬ 
isfy  a  jumble  of  (often  redundant  and  overlapping)  security 
requirements:  unforgeability,  exculpability,  traceabil¬ 
ity,  coalition-resistance,  no-framing,  anonymity,  and 
unlinkability  [13,  8,  12,  29,  3,  9].  To  untangle  and  sim¬ 
plify  these  messy  requirements,  Bellare  et  al.  [4]  investi¬ 
gated  “minimal”  security  requirements  for  group  signature 
schemes.  This  line  of  research  is  very  important,  as  it  par¬ 
allels  the  pursuit  of  similar  requirements  for  secure  pub¬ 
lic  key  encryption  schemes  [26,  3 1 ,  32,  22]  and  secure  key 
exchange  protocols.  The  work  in  [4]  showed  that  two  se¬ 
curity  properties:  full-traceability  and  full-anonymity  are 
sufficient  to  subsume  all  aforementioned  (seven)  require¬ 
ments. 

In  this  paper,  we  argue  that  full-traceability  and 
full-anonymity  are  insufficient  for  certain  realistic  group 
signature  settings.  This  claim  is  based  on  the  observa¬ 
tion  that  group  signatures  are  inherently  application- 
oriented,  and,  thus,  cannot  simply  be  treated  as  a  prim¬ 
itive  in  the  bare  model.  We  identify  two  new  require¬ 
ments:  leak-freedom  and  immediate-revocation  which 
are  necessary  for  a  large  class  of  commercial  applica¬ 
tions.  Informally,  leak-freedom  means  that  a  signer  cannot 
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convince  anyone1  that  it  generated  a  given  group  signa¬ 
ture.  Whereas,  immediate-revocation  means  that  a  group 
member’s  revocation  results  in  immediate  inability  of  gen¬ 
erating  group  signatures,  i.e.,  a  revoked  member  cannot  any 
further  group  signatures. 

Why  is  leak-freedom  important?  One  of  the  main  pur¬ 
poses  of  group  signatures  is  for  an  organization  to  con¬ 
ceal  its  internal  structure.  Suppose  Alice  is  an  employee  of 
a  company  (say,  ABC)  authorized  to  sign  purchase  orders 
and  one  of  the  suppliers  is  another  company  XYZ.  If  Al¬ 
ice  -  without  revealing  her  private  key  or  any  other  long¬ 
term  secret  -  can  convince  XYZ  that  she  is  the  signer  of 
a  given  purchase  order,  she  could  obtain  illegal  kickbacks 
from  XYZ  as  “gratitude”  for  her  supplier  selection.  This 
sort  of  information  leakage  illustrates  potential  abuses  of 
group  signatures,  and  justifies  the  introduction  of  the  leak- 
freedom  property  to  block  such  abuses. 

Why  is  immediate-revocation  important?  We  continue 
with  the  previous  example:  any  purchase  order  signed  by 
Alice  (on  behalf  of  her  employer  ABC)  for  a  supplier  XYZ 
imposes  certain  financial  and/or  legal  responsibilities  on 
ABC.  However,  if  Alice  is  aware  of  her  impending  lay-off, 
she  could,  in  collusion  with  XYZ,  sign  fraudulent  purchase 
orders  for  ABC.  (Note  that  this  problem  is  less  grave  in  tra¬ 
ditional  public  key  infrastructures  where  such  “poisoned” 
signatures  cannot  be  attributed  to  anyone  other  than  the 
signer  herself.)  This  sort  of  abuse  is  possible  in  all  current 
group  signature  schemes,  unless  we  make  very  strong  as¬ 
sumptions  about  underlying  communication  channels  [23]. 
To  this  end,  immediate-revocation  is  necessary  to  block 
such  abuses  without  having  to  introduce  unrealistic  assump¬ 
tions. 

1.1.  Our  Contributions 

This  paper  makes  two  noteworthy  contributions.  First, 
as  mentioned  above,  we  identify  two  important  new  secu¬ 
rity  properties:  leak-freedom  and  immediate-revocation. 
Second,  we  construct  a  secure  and  practical  group  signature 
scheme  that  satisfies  both  new  and  existing  security  proper¬ 
ties.  The  proposed  is  very  efficient:  only  1 1  exponentiations 
are  needed  to  generate  a  group  signature,  while  the  cost 
of  signature  verification  is  equivalent  to  verifying  a  single 
plain  (i.e.,  non-group)  signature,  such  as  RSA.  These  costs 
are  appreciably  lower  than  those  of  state-of-the-art  group 
signature  schemes  [9],  [34], 

The  new  scheme  also  offers  two  important  advantages 
over  previous  work: 

•  It  removes  the  burden  of  having  all  signers  and  all  ver¬ 
ifiers  constantly  obtaining  and  maintaining  up-to-date 


1  Except  the  group  manager  who  can  anyway  always  identify  a  signer. 


’’state  information”  pertaining  to  current  membership. 
In  prior  work,  either  all  signers  and  all  verifiers  had  to 
be  aware  of  public  revocation  lists  [7,  2],  or  all  sign¬ 
ers  had  to  be  aware  of  public  accumulator  ingredient 
lists  [9,  34],  In  the  proposed  scheme,  the  issue  of  dy¬ 
namic  group  membership  is  fully  transparent  to  both 
signers  (group  members)  and  verifiers. 

•  It  relaxes  the  requirement  for  underlying  anonymous 
communication  channels,  since  a  group  member  does 
not  need  to  communicate  directly  with  signature  veri- 
fier(s).  Whereas,  anonymous  communication  channels 
are  essential  (although  rarely  mentioned  explicitly)  in 
previous  group  signature  schemes. 

Outline:  the  rest  of  this  paper  is  organized  as  follows:  the 
next  section  provides  the  definitions  of  group  signatures  and 
their  desired  security  requirements.  Section  3  presents  the 
new  group  signature  scheme.  Section  4  discusses  several  ex¬ 
tensions  and  Section  5  concludes  the  paper. 

2.  Definitions 

Definition  2.1  A  group  signature  scheme  includes  the  fol¬ 
lowing  components: 

Setup  :  a  probabilistic  polynomial-time  algorithm  that ,  on 
input  of  a  security  parameter  k,  outputs  the  specification 
of  a  cryptographic  context  including  the  group  manager’s 
public  key  pkgja  and  secret  key  skgM- 

Join  :  a  protocol  between  the  group  manager  QAA  and  a 
user  that  results  in  the  user  becoming  a  group  member  U. 
Their  common  output  includes  the  user’s  unique  member¬ 
ship  public  keypku,  and  perhaps  some  updated  information 
that  indicates  the  current  state  of  the  system.  The  user’s  out¬ 
put  includes  a  membership  secret  key  sku- 

Revoke  :  an  algorithm  that,  on  input  of  a  group  member’s 
identity  (and  perhaps  her  public  key  pku  )•  outputs  updated 
information  that  indicates  the  current  state  of  the  system  af¬ 
ter  revoking  the  membership  of  a  given  group  member. 

Sign:  a  probabilistic  algorithm  that,  on  input  of  a  group 
public  key  pkgj n,  a  user’s  membership  secret/public  key- 
pair  {sku, pku),  and  a  message  m,  outputs  a  group  signa¬ 
ture  6  ofm. 

Verify :  an  algorithm  that,  on  input  of  a  group  public  key 
pkgM,  a  group  signature  5,  and  a  message  m,  outputs  a  bi¬ 
nary  value  TRUE/FALSE  indicating  whether  5  is  a  valid 
group  signature  (under  pkgj^i)  ofm. 

Open  :  an  algorithm  executed  by  the  group  manager  QAA. 
It  takes  as  input  of  a  message  m,  a  group  signature  S,  the 
group  public  key  pkcM  rind  the  group  manager’s  secret  key 
skgM-  It  first  executes  VERIFY  on  the  first  three  inputs 
and,  if  the  5  is  valid,  outputs  some  incontestable  evidence 
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(e.g.,  a  membership  public  key  pku  and  a  proof)  that  al¬ 
lows  anyone  to  identify  the  actual  signer. 

We  now  specify  the  desired  security  properties  of  a 
group  signature  scheme.  These  properties  are  presented  in¬ 
formally;  a  more  formal  specification  appears  in  the  full  ver¬ 
sion  of  this  paper  [21].  We  note  that,  although  we  use  the  no¬ 
tions  of  full-traceability  and  full-anonymity  introduced  in 
[4],  the  definitions  of  [4]  have  to  be  amended  to  accommo¬ 
date  dynamic  groups,  since  [4]  only  considers  static  groups. 

Definition  2.2  A  secure  group  signature  scheme  must  have 
the  following  properties:  correctness,  full-traceability, 
full-anonymity,  no-misattribution,  as  well  as  the  newly  in¬ 
troduced  leak-freedom  and  immediate-revocation. 

Correctness:  any  signature  produced  by  any  group  mem¬ 
ber  using  Sign  must  be  accepted  by  Verify. 

Full-traceability:  no  subset  of  colluding  group  members 
( even  consisting  of  the  entire  group,  and  even  in  posses¬ 
sion  of  the  group  manager’s  secret  key  for  opening  signa¬ 
tures)  can  create  valid  signatures  that  cannot  be  opened,  or 
signatures  that  cannot  be  traced  back  to  some  member  of 
the  colluding  coalition. 

Full-anonymity:  it  is  computationally  infeasible  for  an  ad¬ 
versary  ( who  is  not  in  possession  of  the  group  manager’s  se¬ 
cret  key  for  opening  signatures)  to  recover  the  identity  of  the 
signer  from  a  group  signature,  even  if  the  adversary  has  ac¬ 
cess  to  the  secret  keys  of  all  group  members. 

No-misattribution:  it  is  computationally  infeasible  for  a 
group  manager  to  provably  attribute  a  group  signature  to 
a  member  who  is  not  the  actual  signer. 

Leak-freedom:  it  is  computationally  infeasible  for  a  signer 
to  convince  anyone  that  it  actually  signed  a  given  message, 
even  if  it  possesses  all  other  signers  ’  secrets,  except  the 
group  manager’s  secret  for  opening  signatures. 

Immediate-revocation:  it  is  computationally  infeasible  for 
a  group  member  revoked  at  time  t  to  generate  a  valid  group 
signature  at  any  time  t'  >  t. 

3.  Our  Construction 

Unlike  most  prior  work,  our  construction  is  designed 
from  a  systems,  rather  than  purely  cryptographic,  perspec¬ 
tive.  (Nonetheless,  cryptography  still  plays  a  major  role  in 
our  construction.)  The  main  idea  is  the  introduction  of  a  new 
entity  referred  to  as  the  mediation  server  (A iS).  M S  is  an 
on-line  partially  trusted  server  that  helps  in  signature  gener¬ 
ation  and  membership  revocation. 

Roughly  speaking,  the  system  functions  as  follows:  each 
time  a  group  member  needs  to  generate  a  signature,  it  some¬ 
how  “identifies”  itself  to  the  mediation  server  which  then 


(if  the  member  is  not  revoked)  produces  a  normal  signature. 
This  normal  signature  is  the  actual  group  signature  and  may 
be  delivered  to  intended  verifier(s).  Nevertheless,  the  mere 
introduction  of  the  mediation  server  does  not  imply  that  we 
can  trivially  obtain  a  group  signature  scheme  possessing  all 
desired  security  properties. 

Caveat:  unlike  prior  non-interactive  group  signature 
schemes,  our  scheme  requires  some  light-weight  interac¬ 
tion  (which  explains  why  it  is  able  to  satisfy  all  of  the 
requirements).  While  interaction  can  be  viewed  as  a  draw¬ 
back,  we  claim  that  it  constitutes  a  reasonable  (even 
small)  price  to  pay  for  additional  attained  security  proper¬ 
ties. 

3.1.  Further  Motivation 

At  this  point,  one  might  wonder  whether  a  practical  so¬ 
lution  that  satisfies  all  aforementioned  requirements  can  be 
obtained  in  a  trivial  fashion.  A  trivial  approach  that  satis¬ 
fies  all  aforementioned  requirements  is  to  make  the  group 
manager  an  on-line  entity  and  have  it  “filter”  all  group  sig¬ 
nature  requests.  Each  group  member  has  a  private  chan¬ 
nel  to  the  group  manager  QM  and,  for  each  message  to 
be  signed,  it  submits  a  message  signed  under  its  normal 
long-term  signature  key.  QM  then  “translates”  each  incom¬ 
ing  signature  into  a  signature  under  its  own  well-known 
group  signature  key.  The  latter  is  then  released  to  the  ver¬ 
ifiers)  and  treated  as  a  group  signature.  With  this  trivial  so¬ 
lution  all  security  properties  (including  leak-freedom  and 
immediate-revocation)  are  satisfied  and  signature  genera¬ 
tion/verification  costs  are  minimal. 

However,  the  trivial  approach  requires  constant  ironclad 
security  of  the  QM.  If  this  can  be  assured,  then  the  trivial 
solution  is  perfect.  However,  having  a  fully  trusted  on-line 
entity  is  undesirable  and  sometimes  simply  unrealistic.2  A 
on-line  QM  would  be  a  single  point  of  failure  in  terms  of 
both  security  (i.e.,  compromise  of  QM  means  compromise 
of  the  whole  system)  and  anonymity  (i.e.,  a  dishonest  QM 
can  arbitrarily  “open”  a  group  signature  without  being  held 
accountable).  It  essentially  “puts  all  eggs  in  one  basket.” 
One  standard  way  to  avoid  a  single  point  of  failure  is  to  uti¬ 
lize  distributed  cryptography,  which  usually  takes  a  heavy 
toll  in  system  complexity,  including:  management,  compu¬ 
tation  and  communication.  To  avoid  unnecessary  complex¬ 
ity  and  subtleties,  we  design  a  system  under  the  guidance 
of  the  well-known  separation  of  duty  principle.  (See  the 
seminal  work  of  Clark  and  Wilson  [20]  for  necessary  back¬ 
ground.)  This  approach,  as  will  be  shown  below,  facilitates 
a  practical  solution  with  a  similar  flavor  of  distributed  secu¬ 
rity,  i.e.,  compromise  of  either  QM  or  the  newly  introduced 


2  For  much  the  same  reasons  that  Certification  Authorities  (CAs)  are  not 
on-line. 
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mediation  server  A iS,  but  not  both,  does  not  imply  com¬ 
plete  compromise  of  the  system. 

3.2.  Model 

Participants:  a  set  of  group  members  U  where  |U|  =  n, 
a  group  manager  QAi  who  admits  group  members,  a  medi¬ 
ation  server  A 4S  who  revokes  group  members  (according 
to  Q Ad’s  instructions)  and  a  set  of  signature  receivers.  Each 
participant  is  modeled  as  a  probabilistic  polynomial-time 
interactive  Turing  machine.  We  assume  that  A 4S  maintains 
a  dynamic  membership  database  DBMember-MS  and  Q Ad 
maintains  a  similar  dynamic  membership  database  DBUser- 
GM.  Moreover,  we  assume  that  A 4S  maintains  a  database 
DBSig-MS  that  records  all  signature  transactions.  We  fur¬ 
ther  assume  that  this  database  is  never  compromised.  In 
practice,  various  uncomplicated  protection  mechanisms  can 
be  utilized.3 

Communication  Channels:  all  communication  chan¬ 
nels  are  asynchronous  and  under  adversary’s  control,  ex¬ 
cept  the  channel  between  QA4  and  A4S.  In  a  typical  sys¬ 
tem  configuration,  we  do  not  assume  any  anonymous  chan¬ 
nels.  However,  we  do  assume  that  the  channels  between  a 
group  member  U  £  U  and  QAi,  and  between  Q A4  and  AiS 
are  authentic.  (This  can  be  implemented  via  standard  tech¬ 
niques  and  is  thus  ignored  in  the  rest  of  the  paper). 

Trust:  precise  specification  of  the  trust  model  is  admit¬ 
tedly  difficult  mainly  because  of  the  introduction  of  the 
new  party  (Ad<S).  Nevertheless,  taking  into  account  the 
separation-of-duty  principle,  we  have  the  following: 

1 .  Q Ad  is  trusted  not  to  introduce  any  illegal  (or  phantom) 
group  members.  However,  QAi  may  want  to  frame  an 
honest  group  member. 

2.  AiS  is  trusted  to  enforce  Q Ad’s  policy,  e.g.,  to  refuse 
services  to  any  and  all  revoked  group  members;  equiv¬ 
alently,  to  produce  group  signatures  only  for  legitimate 
members.  AiS  is  assumed  not  to  misbehave  if  such  ac¬ 
tivity  will  be  traced  to  it.  Nonetheless,  AiS  may  at¬ 
tempt  to:  1)  frame  an  honest  member  into  signing  a 
message,  2)  generate  an  unattributable  group  signa¬ 
ture,  and  3)  compromise  anonymity  of  an  honest  group 
member  (e.g.,  via  out-of-band  means). 

Security  Definitions:  in  order  to  accommodate  the 
new  entity  (Ad<S),  we  need  to  slightly  amend  some  parts 
of  Definition  2.2  for  our  setting.  The  changes  are  minimal 


3  For  example,  MS  can  use  a  decoy  technique  and  insert  (n  —  1) 
well-formed  dummy  transaction  records  for  each  genuine  one.  Alter¬ 
natively,  the  database  can  be  kept  encrypted  with  the  encryption  key 
protected  using  some  advanced  cryptographic  techniques.  These  and 
other  approaches  and  their  respective  merits  are  discussed  in  the  full 
version  of  this  paper  [21]. 


but  necessary  for  the  sake  of  clarity.  (The  rest  of  the  defini¬ 
tions  remains  unchanged.) 

Definition  3.1  Full-traceability:  the  set  of  colluders  can 
additionally  include  AiS. 

Full-anonymity:  the  adversary  is  additionally  allowed  to 
have  access  to  the  secret  key(s)  of  AiS. 

Leak-freedom:  it  is  infeasible  for  a  signer  to  convince  any¬ 
one  (except  AiS)  that  it  generated  a  group  signature;  it  is 
infeasible  for  AiS  to  convince  anyone  (except  QAi)  that  a 
certain  group  member  generated  a  group  signature. 

3.3.  Accountable  Designated  Verifier  Signatures 

We  introduce  the  notion  of  accountable  designated  veri¬ 
fier  signatures  (ADVS)  that  will  serve  as  the  building  block 
in  our  group  signature  scheme.  This  notion  is  an  enhance¬ 
ment  of  the  private  contract  signatures  introduced  in  [25]. 
Informally,  a  private  contract  signature  is  a  designated  ver¬ 
ifier  signature  that  can  be  converted  into  a  universally- 
verifiable  signature  by  either  the  signer  or  a  trusted  third 
party  appointed  by  the  signer.  An  accountable  designated 
verifier  signature  scheme,  on  the  other  hand,  emphasizes  the 
trusted  third  party’s  capability  to  identify  the  actual  signer 
of  a  valid  signature. 

Definition  3.2  Let  T\  and  Pj  be  two  distinct  entities  and 
T  be  a  trusted  third  party.  Suppose  P;  is  the  signer  and 
Pj  is  the  verifier.  An  accountable  designated  verifier  sig¬ 
nature  scheme ,  ADVS,  is  a  tuple  of  polynomial-time  algo¬ 
rithms  (ADVS -Sign,  ADVS-Ver,  ADVS -Proof)  defined 
as  follows: 

ADVS -Sign :  an  algorithm  executed  by  P \  on  message  m 
to  output  an  ADVS:  5  =  ADVS-Sign pi(m,  Pj,  T). 

ADVS-Ver  :  an  algorithm  which  allows  Pj  to  verify  the  va¬ 
lidity  of  an  input  tag  6  on  message  m,  such  that: 
ADVS-Ver (m,Pi,Pj,T;  (5)  = 

TRUE  if  8  =  ADVS-Signp.  (m,  Pj,  T) 

FALSE  otherwise 

ADVS -Proof  :  an  algorithm  executed  by  T  on  input  Pj, 
in,  Pj,  and  tag  8.  It  outputs  a  proof  for  the  predicate 
SignedBy(5,  Pj)  which  is  TRUE  if  8  is  produced  by  Pi,  and 
FALSE  otherwise. 

We  require  that,  if  8  =  ADVS-Sign p.(m.,  Pj  ,T),  then: 
ADVS-Ver(m,  Pj,  Pj,T;  i5)  =  TRUE  and  T  always  out¬ 
puts  a  proof  for  SignedBy(<),  Pj)  being  TRUE. 

Definition  3.3  An  ADVS  scheme  is  secure  if  the  following 
properties  are  satisfied: 

Unforgeability  of  ADVS-Signp^m,  P3 ,  T):  for  any  m,  it 
is  infeasible  for  any  P  f.  {Pi,  Pj}  to  produce  8,  such  that 
ADVS-Ver  (to,  Pj,  Pj,T ■  8)  =  TRUE. 
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Non-transferability  of  ADVS-Sign P.(m,Pj,T):  for 
Pj,  there  is  a  polynomial-time  forgery  algorithm 
which,  for  any  to,  Pi,  and  T,  outputs  5  such  that 
ADVS-Ver (m,  Pt,  Pj,T;  5)  =  TRUE. 

Unforgeability  of  the  proof  for  SignedBy  (5,  Pi):  for  any 
S  =  ADVS-Sign  P.{rn,Pj,T),  it  is  infeasible  for  any 
P  £  {T,Pi}  to  produce  a  proof  for  SignedBy(c),  Pf)  be¬ 
ing  TRUE. 

We  need  to  further  differentiate  between  the  case  that  P,; 
is  able  to  produce  a  proof  for  SignedBy(r),  /' )  and  the  case 
that  Pi  is  unable  to  do  so.  Although  the  former  is  desir¬ 
able  in  the  context  of  private  contract  signatures,  it  is  unde¬ 
sirable  in  our  setting.  This  is  because  private  contract  signa¬ 
tures  only  intend  to  prevent  Pj  transferring  the  one  bit  infor¬ 
mation  SignedByfb,  Pf)  by  any  means.  Whereas,  it  would 
be  very  useful  in  our  context  for  both  p  and  Pj  not  to  be 
able  to  leak  the  bit:  SignedByfb,  Pf).  Thus,  we  have  the  fol¬ 
lowing  definition: 

Definition  3.4  An  ADVS  scheme  is  strongly-secure  if 
in  addition  to  being  a  secure  ADVS  scheme,  it  en¬ 
sures  that  a  signer  Pi  cannot  produce  a  proof  for 
SignedBy((5,  Pf)  with  non-negligible  probability,  where 
5  =  ADVS  -  S  ignP.  (to,  Pj ,  T). 

A  strongly-secure  ADVS  scheme  can  allow  us  to  eas¬ 
ily  construct  a  simple  leak-free  group  signature  system. 
Unfortunately,  we  do  not  know  how  to  construct  such  a 
scheme,  so  we  leave  it  as  an  interesting  open  problem.  In 
order  to  facilitate  a  group  signature  scheme  that  is  leak- 
free  with  immediate-revocation,  we  utilize  a  secure  ADVS 
scheme  that  is  based  on  the  ideas  in  [25].  Due  to  space  lim¬ 
itation,  the  details  appear  in  the  full  version  of  this  paper 
[21]. 

3.4.  Leak-free  Group  Signatures  with  Immediate 
Revocation 

We  are  finally  ready  to  present  a  concrete  construction. 
The  basic  operation  of  our  scheme  is  as  follows.  Given  a 
message  to,  a  group  member  U,  presents  an  ADVS  <5  = 
ADVS-Sign^  (to,  AAS,  Q. Ad)  to  AAS  requesting  (and  ob¬ 
taining)  a  plain  signature  er  =  Sign MS (to).  The  latter 
is  viewed  as  a  group  signature,  for  which  there  is  a  sin¬ 
gle  group-wide  verification  key.  Note  that,  since  Q AA  plays 
the  role  of  a  trusted  third  party  in  the  ADVS  scheme,  it 
can  hold  an  actual  signer  accountable.  We  also  note  that 
our  trust  model  implies  that  there  are  no  issues  with  the 
fair  exchange  of  S  =  ADVS-Sign Ui{m,,AAS,QAA)  for 
a  —  Sign MS (to),  even  if  er  is  returned  to  the  user.  Follow¬ 
ing  the  definition  of  group  signatures,  our  mediated  group 
signature  scheme  consists  of  the  following  procedures: 


SETUP :  this  procedure  initializes  a  group  manager  Q AA 
and  a  mediation  server  AAS. 

1.  C/Afchooses  a  system  wide  security  parameter  k. 
Based  on  it,  (/.Vdchooses  a  discrete-logarithm  based 
crypto-context  as  in  a  normal  Schnorr  signature  set¬ 
ting.  The  parameter  k  and  the  crypto-context  are  fol¬ 
lowed  system-wide  by  all  group  members,  the  AA S 
and  QAA  itself.  QAA  initializes  a  set  U  wherein 
each  group  member  will  be  assigned  a  unique  iden¬ 
tity  Hi  £  U.  f/Afthen  instantiates  an  ADVS  scheme 
ADVS  as  well  as  its  own  public/private  key-pair: 

(Yqm  =  gXgM ,  Xqm) .  Finally,  CJAfinitializes  the 
database  DBUser-GM. 

2.  The  initialization  of  the  mediation  server  AAS  con¬ 
sists  of  the  following:  choose  a  pair  of  ADVS  pub¬ 
lic  and  private  keys  {Yms  =  gXMS  ,Xms)  in 
the  same  crypto-context  as  in  step  1.  Choose  a 
pair  of  keys  for  a  normal  digital  signature  scheme 
SIQ  =  (Gen,  Sign/ns,  Verges)  that  is  secure 
against  adaptive  chosen-message  attack  [27],  De¬ 
note  by  ( pkMSjSkMS )  the  pair  of  group  signature 
verification  and  generation  keys,  where  pk^S  is  pub¬ 
licly  known.4  Initialize  databases  DBMember-MS  and 
DBSig-MS. 

JOIN :  whenever  QAA  decides  to  admit  a  new  member,  it 
first  assigns  a  unique  identity  Ui.  Ui  generates  its  ADVS 
public/private  key-pair:  (Yut  =  gXu*  ,Xut)  ■  Yu,  is  then 
registered  at  the  QAA  and  AAS;  both  DBMember-GM  and 
DBMember-MS  are  updated  accordingly. 

SIGN :  whenever  a  group  member  Ui  wants  to  generate  a 
group  signature  on  message  to,  the  following  protocol  is  ex¬ 
ecuted: 

1.  Ui  sends  AAS  an  ADVS  S  =  ADVS-Signw.  (to,  AAS,  QAA) 
over  an  insecure  public  (and  unauthenticated)  chan¬ 
nel. 

2.  Upon  receipt,  AAS  retrieves  Uf  s  public  key  Yu.  from 
its  database  DBMember-MS.  If  no  entry  is  found,  AAS 
simply  ignores  the  request;  otherwise,  AAS  verifies  6 
by  checking  whether  ADVS-Ver(TO,  AAS,  QAA;  6)  = 
TRUE.  If  it  is,  AAS  then  produces  a  normal  signature 
7  =  Sign_M5(m)  and  inserts  a  new  record  (Ui,5, 7) 
into  its  database  DBSig-MS.  The  signature  7  is  a  group 
signature  on  message  to. 

VERIFY :  given pkMS,  the  public  group  signature  verifica¬ 
tion  key  of  AAS,  and  a  tag  7,  anyone  can  establish  whether 
7  is  a  valid  (group)  signature  by  running  Versus  on  input: 

pkMS ,  ni,  and  7. 


4  We  assume  that  AiS  knows  skj^g  in  its  entirety  so  as  to  prevent  at¬ 
tacks  due  to  incorrect  system  initialization.  This  can  be  ensured  by  uti¬ 
lizing  techniques  due  to  [35]. 
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REVOKE  :  whenever  QM  decides  to  revoke  membership  of 
U, ,  it  first  updates  DBUser-GM  indicating  that  U,  is  revoked 
and  logs  the  necessary  information.  QM  then  informs  MS 
that  Ui  is  revoked,  and  MS  proceeds  to  delete  the  entry 
(LiijYuJ  from  its  database  DBMember-MS.  Consequently, 
all  subsequent  signature  requests  from  U,  will  be  rejected 
by  MS. 

OPEN :  whenever  QM  decides  to  identify  the  actual  signer 
of  signature  7  on  message  m,  the  following  protocol  is  ex¬ 
ecuted  by  QM  and  MS: 

1.  QM  sends  7  to  MS  via  an  authenticated  channel. 

2.  MS  retrieves  (Ui,  S,  7)  from  its  database  and  sends  it 
to  QM  via  the  same  authenticated  channel. 

3.  QM  checks  whether  ADVS-Ver(m,  MS,  QM\ S)  = 
TRUE.  If  so,  QM  executes  ADVS-  Proof  to  pro¬ 
duce  a  proof  for  SignedBy(f),  Ufi)',  otherwise,  QM  con¬ 
cludes  that  MS  is  cheating. 

Remark:  the  above  protocol  does  not  specify  how  a  group 
signature  is  sent  to  its  intended  verifier(s).  There  are  two 
options.  One  way  that  allows  us  to  completely  get  rid  of  the 
anonymous  channels  is  to  let  MS  send  7  directly  to  the  ver¬ 
ifiers).  In  this  case,  there  may  be  a  need  for  a  random  de¬ 
lay  to  address  potential  traffic  analysis  (see  further  discus¬ 
sion  below).  Note  that  this  kind  of  delay  already  exists  in 
the  anonymous  channels  currently  available.  The  other  way 
is  to  let  MS  broadcast  7  so  that  U,  can  receive  and  re-send 
7  to  the  verifier(s)  via  an  anonymous  channel.  We  prefer  the 
former,  however,  a  detailed  analysis  is  deferred  to  [21], 

3.5.  Security  Analysis 

Theorem  3.1  Our  scheme  satisfies  the  requirements 
specified  in  Definition  3.1,  namely  correctness,  full- 
traceability,  full-anonymity,  no-misattribution,  leak- 
freedom,  and  immediate-revocation. 

A  formal  proof  of  this  theorem  appears  in  a  full  version 
of  this  paper  [21].  Intuitively,  the  theorem  holds  because  the 
final  group  signatures  are  generated  using  a  standard  signa¬ 
ture  algorithm,  and  ADVS  makes  it  infeasible  for  the  group 
members  or  MS  to  cryptographically  prove  the  linkage  be¬ 
tween  a  signature  request  and  the  resulting  group  signature. 

4.  Extension  and  Discussion 

Enhancing  anonymity  against  traffic  analysis.  Our 

scheme  does  not  assume  that  the  channel  between  a 
group  member  U  and  the  mediation  server  MS  is  au¬ 
thenticated  or  anonymous.  This  is  because  MS  may 
have  incentives  to  cheat  an  outsider,  which,  in  turn,  im¬ 
plies: 


1.  Even  if  the  adversary  eavesdrops  on  all  channels,  there 
could  still  be  an  out-of-band  channel  between  a  group 
member  and  MS.  Thus,  the  adversary  could  still  be 
fooled. 

2.  MS  can  easily  cheat  an  outsider  by  injecting  a  fake 
ADVS  into  the  network  or  its  database  DBSig-MS. 

However,  an  adversary  might  know  that  MS,  while  not 
being  trusted  to  preserve  anonymity,  does  not  always  inject 
fake  traffic  into  the  network.  Then,  an  adversary  has  a  good 
chance  of  compromising  anonymity  of  some  honest  group 
members  by  means  of  traffic  analysis.  Fortunately,  this  can 
be  avoided  by  using  standard  techniques,  such  as  end-to-end 
encryption  and  traffic  padding. 

On  strongly-secure  ADVS  vs.  secure  ADVS.  In  our  con¬ 
struction  we  utilized  an  ADVS  that  is  secure,  but  not 
strongly-secure.  Consequently,  we  assume  the  secrecy 
of  MS’s  storage,  particularly  DBSig-MS  consisting  of 
all  signature  transaction  entries.  This  is  necessary  in  or¬ 
der  to  avoid  the  following  attack:  If  an  attacker  has 
access  to  an  entry  in  DBSig-MS,  then  Alice  can  con¬ 
vince  the  attacker  that  she  generated  a  group  signature 
Sign^vis^n).  Clearly,  if  a  strongly-secure  ADVS  is  uti¬ 
lized,  we  can  achieve  strictly  stronger  security  that  Alice 
is  unable  to  convince  XYZ  that  she  generated  a  signa¬ 
ture,  even  if  XYZ  has  access  to  the  corresponding  en¬ 
try  in  DBSig-MS.  It  seems  non-trivial  to  ensure  secrecy 
of  DBSig-MS,  while  preserving  other  desirable  prop¬ 
erties.  We  continue  investigating  technical  mechanisms 
that  can  replace  this  rather  strong  assumption  regard¬ 
ing  database  secrecy  [21]. 

Denial-of-Service  (DoS)  attacks.  Recall  than  MS  always 
performs  a  number  of  modular  exponentiations  before  it  is 
able  to  determine  whether  an  incoming  ADVS  is  valid.  This 
opens  the  door  for  DoS  attacks  on  MS.  To  counter  such  at¬ 
tacks,  we  suggest  a  simple  solution.  The  idea  is  to  let  each 
Ui  and  MS  share  a  unique  secret  key  w-i .  Each  signature  re¬ 
quest  from  Ui  must  also  be  accompanied  by  an  authentica¬ 
tion  token  computed  over  the  request  with  the  key  w, .  When 
processing  a  request,  MS  verifies  the  authentication  token 
before  performing  much  more  expensive  validation  of  the 
ADVS.  Note  that  this  additional  authentication  is  does  not 
in  any  way  influence  security  properties  of  our  scheme.  Of 
course,  this  is  only  a  partial  solution  since  an  adversary  can 
still  mount  a  DoS  attack  on  the  MS’s  network  interface. 

4.1.  Related  Work 

This  paper  can  be  viewed  as  one  of  many  efforts  pursu¬ 
ing  practical  and  secure  group  signature  or  identity  escrow 
schemes  [18,  19,  13,  29,  1,  11],  as  well  as  anonymous  cre¬ 
dential  systems  [16,  17,  30,  10,  14].  Among  them,  the  prior 
work  most  relevant  to  this  paper  is  [11],  which  presented  an 
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identity  escrow  scheme  (and  a  corresponding  group  signa¬ 
ture  scheme)  with  the  appointed  verifier  property.  The  mo¬ 
tivation  was  to  obtain  a  scheme  where  a  group  member  can 
only  convince  one  or  more  appointed  verifiers  of  its  mem¬ 
bership,  while  no  other  party  can  verify  membership  even  if 
the  signer  cooperates  fully. 

Note  that  there  is  a  difference  between  the  appointed 
verifier  property  in  [11]  and  the  leak-freedom  property 
specified  in  this  paper.  Specifically,  the  scheme  in  [11],  by 
definition,  allows  a  signer  to  convince  the  designated  ver¬ 
ifiers  that  it  is  authorized  to  conduct  the  relevant  transac¬ 
tions.  Cast  this  in  our  example  scenario,  Alice  can  always 
convince  XYZ  that  she  is  authorized  to  sign  purchase  or¬ 
ders.  This  capability  can  result  in  the  leakage  (outlined  in 
Section  1)  we  meant  to  avoid!  Besides  achieving  the  strictly 
stronger  leak-freedom,  our  scheme  is  more  efficient  than 
[11]  which  requires  both  a  signer  and  a  verifier  to  compute 
more  than  17 k  exponentiations,  where  k  is  a  security  pa¬ 
rameter  (say,  k  =  80).  Moreover,  membership  revocation 
is  not  supported  in  [11],  whereas,  we  achieve  immediate- 
revocation  which  has  only  been  explored  in  the  context  of 
traditional  PKI-s  [6]. 

A  credential  system  is  a  system  where  users  can  obtain 
credentials  from  organizations  and  demonstrate  possession 
of  these  credentials  [16,  17,  30,  10,  14].  Chaum  and  Evertse 
[17]  presented  a  general  scheme  using  a  semi-trusted  TTP 
common  to  multiple  organizations.  However,  their  scheme 
is  impractical.  The  credential  system  by  Lysianskaya  et  al. 
[30]  captures  many  of  the  desirable  properties.  Camenisch 
and  Lysianskaya  [10]  presented  a  better  solution  with  in¬ 
gredients  from  a  secure  group  signature  scheme  of  [1],  The 
prototype  implementation  of  [10]  was  done  by  Camenisch 
and  van  Herreweghen  [14].  This  scheme  requires  both  sign¬ 
ers  and  verifiers  to  compute  22  modular  exponentiations. 
Their  advanced  scheme  which  provides  all-or-nothing  non¬ 
transferability  (to  discourage  a  signer  from  sharing  its  cre¬ 
dentials  with  other  parties)  requires  both  signer  and  verifier 
to  compute  200  exponentiations. 

The  notion  of  abuse-freedom  or  abuse-freeness  [25]  is 
weaker  than  leak-freedom  because  the  former  intends  only 
to  prevent  the  designated  verifier  from  being  able  to  trans¬ 
fer  the  information  about  the  actual  signer,  whereas  the  lat¬ 
ter  intends  to  prevent  a  signer  as  well  as  the  designated  ver¬ 
ifier  from  being  able  to  transfer  the  same  information.  Fi¬ 
nally,  we  remark  that  leak-freedom  is  similar  to  the  prop¬ 
erty  called  receipt-freedom  or  receipt-freeness  in  the  context 
of  voting  schemes  [5,  28],  and  its  closely  related  variants 
called  deniable  encryption  [15]  and  deniable  proof  [24]. 

5.  Conclusion 

We  identified  two  properties,  namely  leak-freedom  and 
immediate-revocation,  that  are  crucial  for  a  large  class  of 


group  signature  applications.  We  also  constructed  a  scheme 
that  achieves  all  of  traditional  and  newly-introduced  goals 
by  following  a  systems  architectural  approach.  Our  scheme 
is  practical  and  easy  to  implement,  because  it  needs  only  1 1 
exponentiations  for  a  group  member  to  generate  a  group  sig¬ 
nature  and  one  normal  signature  verification  for  its  valida¬ 
tion.  Another  contribution  of  this  paper  is  the  relaxation  on 
the  requirement  for  anonymous  communication  channels, 
which  are  essential  in  all  previous  schemes. 

In  addition  to  the  already  mentioned  issues  (including 
the  protection  of  the  server  databases,  and  the  robustness 
against  denial-of-service  attacks)  that  need  further  investi¬ 
gations,  our  work  also  incurs  some  problems  that  are  inter¬ 
esting  in  an  even  more  general  context: 

1.  How  to  construct  a  practical  strongly-secure  ADVS 
scheme? 

2.  How  to  construct  a  leak-free  group  signature  scheme 
with  immediate  revocation  that  does  not  rely  on  a  me¬ 
diation  server?  Although  we  believe  that  the  existence 
of  a  mediation  server  is  more  realistic  than  the  exis¬ 
tence  of  (for  instance)  a  time-stamping  service,  it  is 
nevertheless  conceivable  that  other  alternatively  con¬ 
structions  could  fit  well  into  different  specific  applica¬ 
tion  scenarios. 

3.  How  to  achieve  a  stateless  A fSl  This  is  not  trivial  be¬ 
cause,  otherwise,  the  binding  of  an  ADVS  signature  (or 
any  other  token  with  the  desired  properties)  and  a  nor¬ 
mal  signature  would  allow  A 4S  to  convince  an  out¬ 
sider  of  the  identity  of  the  actual  signer. 
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We  present  a  new  approach  for  fine-grained  control  over  users’  security  privileges  (fast  revocation 
of  credentials)  centered  around  the  concept  of  an  on-line  semi-trusted  mediator  (SEM).  The  use  of 
a  SEM  in  conjunction  with  a  simple  threshold  variant  of  the  RSA  cryptosystem  (mediated  RSA) 
offers  a  number  of  practical  advantages  over  current  revocation  techniques.  The  benefits  include 
simplified  validation  of  digital  signatures,  efficient  certificate  revocation  for  legacy  systems  and  fast 
revocation  of  signature  and  decryption  capabilities.  This  paper  discusses  both  the  architecture 
and  the  implementation  of  our  approach  as  well  as  its  performance  and  compatibility  with  the 
existing  infrastructure.  Experimental  results  demonstrate  its  practical  aspects. 

Categories  and  Subject  Descriptors:  E.3.3  [Data]:  Data  Encryption — Public  Key  Crypto sy stems; 
K.6.5  [Management  of  Computing  and  Information  Systems]:  Security  and  Protection 

General  Terms:  Algorithms,  Security 

Additional  Key  Words  and  Phrases:  Certificate  Revocation,  Digital  Signatures,  Public  Key  In¬ 
frastructure 


1.  INTRODUCTION 

We  begin  this  paper  with  an  example  to  illustrate  the  premise  for  this  work.  Con¬ 
sider  an  organization  -  industrial,  government,  or  military  -  where  all  employees 
(referred  to  as  users)  have  certain  authorizations.  We  assume  that  a  Public  Key 
Infrastructure  (PKI)  is  available  and  all  users  have  digital  signature,  as  well  as 
en/de-cryption,  capabilities.  In  the  course  of  performing  routine  everyday  tasks, 
users  take  advantage  of  secure  applications,  such  as  email,  file  transfer,  remote 
log-in  and  web  browsing. 
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Now  suppose  that  a  trusted  user  (Alice)  does  something  that  warrants  immediate 
revocation  other  security  privileges.  For  example,  Alice  might  be  fired,  or  she  may 
suspect  that  her  private  key  has  been  compromised.  Ideally,  immediately  following 
revocation,  the  key  holder,  either  Alice  herself  or  an  attacker,  should  be  unable  to 
perform  any  security  operations  and  use  any  secure  applications.  Specifically,  this 
might  mean: 

-  The  key  holder  cannot  read  any  secure  email.  This  includes  encrypted  email  that 

already  resides  on  Alice’s  email  server  (or  local  host)  and  possible  future  email 
erroneously  encrypted  for  Alice.  Although  encrypted  email  may  be  delivered  to 
Alice’s  email  server,  the  key  holder  should  be  unable  to  decrypt  it. 

-  The  key  holder  cannot  generate  valid  digital  signatures  on  any  further  messages. 

However,  signatures  generated  by  Alice  prior  to  revocation  may  need  to  remain 
valid. 

-  The  key  holder  cannot  authenticate  itself  to  corporate  servers  (and  other  users) 

as  a  legitimate  user. 

Throughout  the  paper,  we  use  email  as  an  example  application.  While  it  is  a 
popular  mechanism  for  general-purpose  communication,  our  rationale  also  applies 
to  other  secure  means  of  information  exchange. 

To  provide  immediate  revocation  it  is  natural  to  first  consider  traditional  re¬ 
vocation  techniques.  Many  revocation  methods  have  been  proposed;  they  can  be 
roughly  classified  into  two  prominent  types:  1)  explicit  revocation  structures  such 
as  Certificate  Revocation  Lists  (CRLs)  and  variations  on  the  theme,  and  2)  real 
time  revocation  checking  such  as  the  Online  Certificate  Status  Protocol  (OCSP) 
[Myers  et  al.  1999]  and  its  variants.  In  both  cases,  some  trusted  entities  are  ulti¬ 
mately  in  charge  of  validating  user  certificates.  However,  the  above  requirements 
for  immediate  revocation  are  impossible  to  satisfy  with  existing  techniques.  This 
is  primarily  because  they  do  not  provide  fine-grained  enough  control  over  users’ 
security  capabilities.  Supporting  immediate  revocation  with  existing  revocation 
techniques  would  result  in  heavy  performance  cost  and  very  poor  scalability,  as 
discussed  in  Section  8. 

As  pointed  out  in  [McDaniel  and  Rubin  2000],  since  each  revocation  technique 
exhibits  a  unique  set  of  pros  and  cons,  the  criteria  for  choosing  the  best  tech¬ 
nique  should  be  based  on  the  specifics  of  the  target  application  environment.  Fast 
revocation  and  fine-grained  control  over  users’  security  capabilities  are  the  moti¬ 
vating  factors  for  our  work.  However,  the  need  for  these  features  is  clearly  not 
universal  since  many  computing  environments  (e.g.,  a  typical  university  campus) 
are  relatively  “relaxed”  and  do  not  warrant  employing  fast  revocation  techniques. 
However,  there  are  plenty  of  government,  corporate  and  military  settings  where  fast 
revocation  and  fine-grained  control  are  very  important. 


Organization.  This  paper  is  organized  as  follows.  The  next  section  provides 
an  overview  of  our  work.  The  technical  details  of  the  architecture  are  presented 
in  Section  3  and  Section  4,  respectively.  Then,  Section  5  shows  four  extensions. 
Sections  6  and  7,  describe  the  implementation  and  performance  results,  respectively. 
A  comparison  of  with  current  revocation  techniques  is  presented  Section  8,  followed 
by  the  overview  of  related  work  in  Section  8.2  and  a  summary  in  Section  9. 
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2.  OVERVIEW 


We  refer  to  our  approach  as  the  SEM  architecture.  The  basic  idea  is  as  fol¬ 
lows:  We  introduce  a  new  entity,  referred  to  as  a  SEM  (SEcurity  Mediator):  an 
online  semi-trusted  server.  To  sign  or  decrypt  a  message,  a  client  must  first  ob¬ 
tain  a  message-specific  token  from  its  SEM.  Without  this  token,  the  user  cannot 
accomplish  the  intended  task.  To  revoke  the  user’s  ability  to  sign  or  decrypt,  the 
security  administrator  instructs  the  SEM  to  stop  issuing  tokens  for  that  user’s  fu¬ 
ture  request.  At  that  instant,  the  user’s  signature  and/or  decryption  capabilities 
are  revoked.  For  scalability  reasons,  a  single  SEM  serves  many  users. 

We  stress  that  the  SEM  architecture  is  transparent  to  non-SEM  users,  i.e.,  a  SEM 
is  not  involved  in  encryption  or  signature  verification  operations.  With  SEM’s  help, 
a  SEM  client  (Alice)  can  generate  standard  RSA  signatures,  and  decrypt  standard 
ciphertext  messages  encrypted  with  her  RSA  public  key.  Without  SEM’s  help,  she 
cannot  perform  either  of  these  operations.  This  backwards  compatibility  is  one  of 
our  main  design  principles. 

Another  notable  feature  is  that  a  SEM  is  not  a  fully  trusted  entity.  It  keeps 
no  client  secrets  and  all  SEM  computations  are  checkable  by  its  clients.  However, 
a  SEM  is  partially  trusted  since  each  signature  verifier  implicitly  trusts  it  to  have 
checked  the  signer’s  (SEM’s  client’s)  certificate  status  at  signature  generation  time. 
Similarly,  each  encryptor  trusts  a  SEM  to  check  the  decryptor’s  (SEM’s  client’s) 
certificate  status  at  message  decryption  time.  We  consider  this  level  of  trust  rea¬ 
sonable,  especially  since  a  SEM  serves  a  multitude  of  clients  and  thus  represents  an 
organization  (or  a  group). 

In  order  to  experiment  and  gain  practical  experience,  we  prototyped  the  SEM 
architecture  using  the  popular  OpenSSL  library.  SEM  is  implemented  as  a  daemon 
process  running  on  a  secure  server.  On  the  client  side,  we  built  plug-ins  for  the 
Eudora  and  Outlook  email  clients  for  signing  outgoing,  and  decrypting  incoming, 
emails.  Both  of  these  tasks  are  performed  with  the  SEM’s  help.  Consequently, 
signing  and  decryption  capabilities  can  be  easily  revoked. 

It  is  natural  to  ask  whether  the  same  functionality  can  be  obtained  with  more 
traditional  security  approaches  to  fine-grained  control  and  fast  credential  revoca¬ 
tion,  such  as  Kerberos.  Kerberos  [Neuman  and  Ts’o  1994],  after  all,  has  been  in 
existence  since  the  mid-80s  and  tends  to  work  very  well  in  corporate-style  settings. 
However,  Kerberos  is  awkward  in  heterogeneous  networks  such  as  the  Internet;  its 
inter-realm  extensions  are  difficult  to  use  and  require  a  certain  amount  of  manual 
setup.  Furthermore,  Kerberos  does  not  inter-operate  with  modern  PKI-s  and  does 
not  provide  universal  origin  authentication  offered  by  public  key  signatures.  On  the 
other  hand,  the  SEM  architecture  is  fully  compatible  with  existing  PKI  systems.  In 
addition,  the  SEM  is  only  responsible  for  revocation.  Unlike  a  Kerberos  server,  the 
SEM  cannot  forge  user  signatures  or  decrypt  messages  intended  for  users.  As  we 
discuss  later  in  the  paper,  our  approach  is  not  mutually  exclusive  with  Kerberos- 
like  intra-domain  security  architectures.  We  assert  that  the  SEM  architecture  can 
be  viewed  as  a  set  of  complementary  security  services. 
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2.1  Decryption  and  signing  in  the  SEM  architecture 

We  now  describe  in  more  detail  how  decryption  and  digital  signature  generation 
are  performed  in  the  SEM  architecture: 

-  Decryption:  suppose  that  Alice  wants  to  decrypt  an  email  message  using  her 
private  key.  Recall  that  public  key-encrypted  email  is  usually  composed  of  two 
parts:  (1)  a  short  preamble  containing  a  per-message  key  encrypted  with  Alice’s 
public  key,  and  (2)  the  body  containing  the  actual  email  message  encrypted  using 
the  per-message  key.  To  decrypt,  Alice  first  sends  the  preamble  to  her  SEM.  SEM 
responds  with  a  token  which  enables  Alice  to  complete  the  decryption  of  the  per- 
message  key  and,  ultimately,  to  read  her  email.  However,  this  token  contains  no 
information  useful  to  anyone  other  than  Alice.  Hence,  communication  with  the 
SEM  does  not  need  to  be  secret  or  authenticated.  Also,  interaction  with  the  SEM 
is  fully  managed  by  Alice’s  email  reader  and  does  not  require  any  intervention  on 
Alice’s  part.  If  Alice  wants  to  read  her  email  offline,  the  interaction  with  the  SEM 
takes  places  at  the  time  Alice’s  email  client  downloads  her  email  from  the  mail 
server. 

Signatures:  suppose  that  Alice  wishes  to  sign  a  message  using  her  private  key. 
She  sends  a  (randomized)  hash  of  the  message  to  her  SEM  which,  in  turn,  responds 
with  a  token  (also  referred  to  as  a  half-signature)  enabling  Alice  to  generate  the 
signature.  As  with  decryption,  this  token  contains  no  useful  information  to  anyone 
other  than  Alice. 

2.2  Other  Features 

Our  initial  motivation  for  introducing  a  SEM  is  to  enable  immediate  revocation  of 
Alice’s  public  key.  As  a  byproduct,  the  SEM  architecture  provides  additional  ben¬ 
efits.  In  particular,  validation  of  signatures  generated  with  the  help  of  a  SEM  does 
not  require  the  verifier  to  consult  a  CRL  or  a  revocation  authority:  the  existence 
of  the  a  verifiable  signature  implies  that  the  signer  was  not  revoked  at  the  time  the 
signature  was  generated.  Consequently,  signature  validation  is  greatly  simplified. 

More  importantly,  the  SEM  architecture  enables  revocation  in  legacy  systems  that 
do  not  support  certificate  revocation.  Consider  a  legacy  system  performing  digital 
signature  verification.  Often,  such  systems  have  no  certificate  status  checking  ca¬ 
pabilities.  For  example,  old  browsers  (e.g.,  Netscape  3.0)  verify  server  certificates 
without  any  means  for  checking  certificate  revocation  status.  Similarly,  Microsoft’s 
Authenticode  system  in  Windows  NT  (used  for  verifying  signatures  on  executable 
code)  does  not  support  certificate  revocation.  In  the  SEM  architecture,  certificate 
revocation  is  provided  without  requiring  any  change  to  the  verification  process  in 
such  legacy  systems.  The  only  aspect  that  needs  changing  is  signature  genera¬ 
tion.  Fortunately,  in  many  settings  (such  as  code  signing)  the  number  of  entities 
generating  signatures  is  significantly  smaller  than  that  of  entities  verifying  them. 

Semantics.  The  SEM  architecture  naturally  provides  the  following  semantics  for 
digital  signatures: 

Binding  Signature  Semantics:  a  digital  signature  is  considered  valid 
if  the  public  key  certificate  associated  with  the  private  key  used  to  gen¬ 
erate  the  signature  was  valid  at  the  time  the  signature  was  issued. 
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According  to  this  definition,  all  verifiable  signatures  by  virtue  of  their  existence 
-  are  generated  prior  to  revocation  and,  hence,  are  considered  valid.  Binding  sig¬ 
nature  semantics  are  natural  in  many  settings,  such  as  business  contracts.  For 
example,  suppose  Alice  and  Bob  enter  into  a  contract.  They  both  sign  the  contract 
at  time  T .  Bob  begins  to  fulfill  the  contract  and  incurs  certain  costs  in  the  process. 
Now,  suppose  at  time  T'  >  T,  Alice  revokes  her  own  certificate  (e.g.,  by  “losing” 
her  private  key).  Is  the  contract  valid  at  time  T'l  With  binding  semantics,  Alice 
is  still  bound  to  the  contract  since  it  was  signed  at  time  T  when  her  certificate 
was  still  valid.  In  other  words,  Alice  cannot  nullify  the  contract  by  causing  her 
own  certificate  to  be  revoked.  We  note  that  binding  semantics  are  inappropriate 
in  some  scenarios.  For  example,  if  a  certificate  is  obtained  from  a  CA  under  false 
pretense,  e.g.,  Alice  masquerading  as  Bob,  the  CA  should  be  allowed  to  declare  at 
any  time  that  all  signatures  generated  with  that  certificate  are  invalid. 

Implementing  binding  signature  semantics  with  existing  revocation  techniques  is 
non-trivial,  as  discussed  in  Section  8.  Whenever  Bob  verifies  a  signature  generated 
by  Alice,  Bob  must  also  check  that  Alice’s  certificate  was  valid  at  the  time  the 
signature  was  generated.  In  fact,  every  verifier  of  Alice’s  signature  must  perform 
this  certificate  validation  step.  Note  that,  unless  a  trusted  time-stamping  service 
is  involved  in  generating  all  of  Alice’s  signatures,  Bob  cannot  trust  the  timestamp 
included  by  Alice  in  her  signatures. 

Not  surprisingly,  implementing  binding  semantics  with  the  SEM  architecture  is 
trivial.  To  validate  Alice’s  signature,  a  verifier  need  only  verify  the  signature  itself. 
There  is  no  need  to  check  the  status  of  Alice’s  certificate.  (We  are  assuming  here 
that  revocation  of  Alice’s  key  is  equivalent  to  revocation  of  Alice’s  certificate.  In 
general,  however,  Alice’s  certificate  may  encode  many  rights,  not  just  the  right 
to  use  her  key(s).  It  is  then  possible  to  revoke  only  some  of  these  rights  while 
not  revoking  the  entire  certificate.)  Once  Alice’s  certificate  is  revoked,  she  can  no 
longer  generate  valid  signatures.  Therefore,  the  mere  existence  of  a  valid  signature 
implies  that  Alice’s  certificate  was  valid  at  the  time  the  signature  was  issued. 


3.  MEDIATED  RSA 

We  now  describe  in  detail  how  a  SEM  interacts  with  clients  to  generate  tokens. 
The  SEM  architecture  is  based  on  a  variant  of  RSA  which  we  call  Mediated  RSA 
(mRSA).  The  main  idea  is  to  split  each  RSA  private  key  into  two  parts  using 
simple  2-out-of-2  threshold  RSA  [Gemmel  1997;  Boyd  1989].  One  part  is  given  to 
a  client  and  the  other  is  given  to  a  SEM.  If  the  client  and  its  SEM  cooperate,  they 
employ  their  respective  half- keys  in  a  way  that  is  functionally  equivalent  to  (and 
indistinguishable  from)  standard  RSA.  The  fact  that  the  private  key  is  not  held  in 
its  entirety  by  any  one  party  is  transparent  to  the  outside  world,  i.e. ,  to  the  those 
who  use  the  corresponding  public  key.  Also,  knowledge  of  a  half- key  cannot  be 
used  to  derive  the  entire  private  key.  Therefore,  neither  the  client  nor  the  SEM 
can  decrypt  or  sign  a  message  without  mutual  consent.  (Recall  that  a  single  SEM 
serves  many  clients.) 

The  mRSA  method  is  composed  of  three  algorithms:  mRSA  key  generation, 
mRSA  signatures,  and  mRSA  decryption.  We  present  them  in  the  next  section. 
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3.1  mRSA  Key  Generation 

Similar  to  RSA,  each  client  Ui  has  a  unique  public  key  and  private  key.  The  public 
key  PKi  includes  nl  and  e$,  where  the  former  is  a  product  of  two  large  distinct 
primes  ( Pi,qi )  and  e*  is  an  integer  relatively  prime  to  <j)(rii )  =  (p,  —  1  )(g,  —  1). 

Logically,  there  is  also  a  corresponding  RSA  private  key  SKi  =  (rij,  d,)  where 
di  *  6i  =  1  mod  However,  as  mentioned  above,  no  one  party  has  possession 

of  di .  Instead,  di  is  effectively  split  into  two  parts:  df  and  dfem  which  are  secretly 
held  by  the  client  Ui  and  a  SEM,  respectively.  The  relationship  among  them  is: 

di  =  d\ern  +  d^  mod  <j)(rii) 

Unlike  plain  RSA,  an  individual  client  Ui  cannot  generate  its  own  mRSA  keys. 
Instead,  a  trusted  party  (most  likely,  a  CA)  initializes  and  distributes  the  mRSA 
keys  to  clients.  The  policy  for  authenticating  and  authorizing  clients’  key  generation 
requests  is  not  discussed  in  this  paper.  Once  a  client’s  request  is  received  and 
approved,  a  CA  executes  the  mRSA  key  generation  algorithm  described  below. 

mRSA  Key  Setup.  CA  generates  a  distinct  set:  {p,,  < p,  e»,  di,  dfem,  d“}  for  {7*. 
The  first  four  values  are  generated  as  in  standard  RSA.  The  fifth  value,  dfem,  is 
a  random  integer  in  the  interval  [1, n»] ,  where  rij  =  Piqi-  The  last  value  is  set  as: 
d,^  =  di  —  dfem  mod  <p(rii).  We  show  the  protocol  in  Figure  1. 


Algorithm:  mRSA. key  (executed  by  CA) 


Let 

k  (even)  be  a  security  parameter 

(i) 

Generate  random  A; / 2-bit  primes:  pi , 

(2) 

Hi  <— 

Piqi 

(3) 

r 

ei  <— 

(4) 

< 

l/ej  mod 

(5) 

jsem 

ai 

A-  n;  —  l} 

(6) 

*Ui  <- 

(di  -  dfem)  mod  <t>(rn) 

(7) 

SKi  ■ 

*-  (ni,df) 

(8) 

PKi 

<—  ( rii,ei ) 

Fig.  1.  mRSA  Key  Generation  Algorithm 

After  CA  computes  the  above  values,  dfem  is  securely  communicated  to  the  SEM 
and  d^  is  communicated  to  Ui.  The  details  of  this  step  are  elaborated  upon  in 
Section  6. 

3.2  mRSA  Signatures 

According  to  PKCS1  v2.1  [Labs  2002],  RSA  signature  generation  is  composed  of 
two  steps:  message  encoding  and  cryptographic  primitive  computation.  The  first 
step  is  preserved  in  mRSA  without  any  changes.  However,  the  second  step  requires 
SEM’s  involvement  since,  in  mRSA,  a  client  does  not  possess  its  entire  private  key. 

We  denote  by  EC ()  and  DCQ  the  encoding  and  decoding  functions,  respectively. 
Both  encodings  include  hashing  the  input  message  m  using  a  collision  resistant  hash 
function.  For  now,  we  assume  the  message  encoding  function  EC( )  is  determin¬ 
istic.  A  user  (Ui)  generates  a  signature  on  a  message  m  as  follows: 
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1.  Preprocessing:  Ui  sends  the  message  m  to  the  SEM. 

2.  Computation: 

SEM  checks  that  Ui  is  not  revoked  and,  if  so,  computes  a  partial  signature 
PSsem  =  EC(m)di  mod  n,  and  replies  with  it  to  the  client.  This  PSsem  is 
the  token  enabling  signature  generation  on  message  to. 

-  Concurrently,  U-t  computes  PSU  =  EC(m)di  mod  n* 

3.  Output:  Ui  receives  PSsem  and  computes  Si(m)  =  ( PSsem  *  PSU)  mod  n*.  It 
then  verifies  S'j(m)  as  a  standard  RSA  signature.  (This  step  also  verifies  the 
SEM’s  computation.)  If  the  signature  is  valid,  Ui  outputs  it. 

The  algorithm  is  shown  in  Figure  2. 


Algorithm  mRSA.sign  (executed  by  User  and  SEM) 

(1)  USER:  Send  m  to  SEM. 

(2)  In  parallel: 

2.1.  SEM: 

(a)  If  USER  revoked  return  (ERROR); 

(b)  PSsem  <—  £C(m)'i''m  mod  m 

where  ECQ  is  the  EMSA-PKCSl-vl_5  encoding  function,  recommended 
in  [Labs  2002]. 

(c)  send  PSsem  to  USER 

2.2.  USER: 

(a)  PSU  <—  EC(m)di  mod  n; 

(3)  USER:  S  <—  PSsem  *  PSU  mod  rij 

(4)  USER:  Verify  that  S  is  a  valid  signature  on  m  under  the  public  key  ( N ,  e,j.  If 
not  then  return  (ERROR) 

(5)  USER:  return  (m,S) 


Fig.  2.  mRSA  Signature  Algorithm 

We  observe  that  the  resulting  mRSA  and  RSA  signatures  are  indistinguishable 
since:  wdi  *  wdi  =  wdi  +di  =  wdi  mod  n.  Consequently,  the  mRSA  signature 
generation  process  is  transparent  to  eventual  signature  verifiers,  since  both  the 
verification  process  and  the  signature  format  are  identical  to  those  in  standard 
RSA. 

Security.  We  briefly  discuss  the  security  of  the  signature  scheme  of  Figure  2.  At 
a  high  level,  we  require  two  properties:  (1)  the  user  cannot  generate  signatures  after 
being  revoked,  and  (2)  the  SEM  cannot  generate  signatures  on  behalf  of  the  user. 
For  both  properties  we  require  existential  unforgeability  under  a  chosen  message 
attack.  Precise  security  models  for  this  scheme  (used  in  a  slightly  different  context 
of  multicative  version  of  mRSA)  can  be  found  in  [Bellare  and  Sandhu  2001]  where 
a  proof  of  security  is  given. 

Randomized  encodings.  Note  that,  we  assumed  above  that  the  encoding  proce¬ 
dure  ECQ  is  deterministic,  as  in  EMSA-PKCSl-vl_5  [Labs  2002]  encoding  and  Full 
Domain  Hash  (FDH)  encoding  [Bellare  and  Rogaway  1996].  If  ECQ  is  a  random¬ 
ized  encoding,  such  as  EMSA-PSS  [Labs  2002],  we  have  to  make  sure  both  the  user 
and  SEM  use  the  same  randomness  so  that  the  resulting  signature  is  valid.  At  the 
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same  time,  to  prevent  the  user  from  generating  signatures  without  its  help,  the  SEM 
has  to  ensure  that  the  random  bits  used  for  the  encoding  are  chosen  independently 
at  random.  Therefore,  we  cannot  simply  let  the  user  choose  the  randomness  for  the 
encoding.  Instead,  the  user  and  the  SEM  must  engage  in  a  two-party  coin  flipping 
protocol  to  generate  the  required  shared  randomness.  Neither  party  can  bias  the 
resulting  random  bits.  Consequently,  these  bits  can  be  used  as  the  randomness 
needed  for  the  encoding  function.  However,  when  using  deterministic  encoding, 
such  as  EMSA-PKCSl-vl_5,  there  is  no  need  for  this  step. 

We  note  that  in  the  above  protocol  the  user  sends  the  entire  message  to  to  the 
SEM  in  step  (1).  For  privacy  reasons,  one  might  instead  consider  sending  the  digest 
EC(m)  the  SEM.  This  would  eliminate  the  difficulty  with  randomized  encodings 
mentioned  above.  Unfortunately,  the  resulting  system  cannot  be  shown  as  secure 
as  the  underlying  RSA  signature  scheme.  Specifically,  when  only  sending  EC(m) 
to  SEM,  we  are  unable  to  prove  that  the  user  cannot  generate  signatures  after  being 
revoked.  The  problem  is  that,  while  the  user  is  not  revoked,  the  SEM  functions  as 
an  unrestricted  RSA  inversion  oracle  for  the  user.  For  example,  the  user  can  use  the 
attack  of  [Desmedt  and  Odlyzko  1985]  to  generate  signatures  after  being  revoked. 
A  proof  of  security  is  still  possible,  using  a  strong  assumption  on  RSA:  a  variant  of 
the  “One-more  RSA  Assumption”  [Bellare  and  Sandhu  2001].  Nevertheless,  when 
using  EMSA-PKCSl-vl_5  [Labs  2002]  encoding,  which  is  only  heuristically  secure, 
it  might  be  fine  to  send  EC(m)  to  the  SEM. 

3.3  mRSA  Decryption 

Recall  that  PKCS1  [Labs  2002]  stipulates  that  an  input  message  to  must  be  OAEP- 
encodecl  before  carrying  out  the  actual  RSA  encryption.  We  use  ECoaep{ )  and 
DCoaep  ()  to  denote  OAEP  encoding  and  decoding  functions,  respectively.  The 
encryption  process  is  identical  to  standard  RSA,  where  c  =  ECoaep(rn)ei  mod  n, 
for  each  client  U,:.  Decryption,  on  the  other  hand,  is  very  similar  to  mRSA  signature 
generation  described  above. 

1.  Ui  obtains  encrypted  message  c  and  forwards  it  to  its  SEM. 

SEM  checks  that  Ut  is  not  revoked  and,  if  so,  computes  a  partial  clear-text 
PCgem  =  cdi  mod  rij  and  replies  to  the  client. 

-  concurrently,  Ui  computes  PCU  =  cdi  mod  n,. 

2.  Ui  receives  PCsem  and  computes  d  =  PCsem  *  PCU  mod  m.  If  OAEP  decoding 
of  d  succeeds,  Ui  outputs  the  clear-text  to  =  DCoaep(d). 

Security.  We  now  briefly  discuss  the  security  of  the  mRSA  decryption  scheme 
shown  in  Figure  3.  At  a  high  level,  we  require  two  properties:  (1)  the  user  cannot 
decrypt  ciphertexts  encrypted  with  the  user’s  public  key  after  being  revoked,  and 
(2)  the  SEM  cannot  decrypt  messages  encrypted  using  the  user’s  public  key.  For 
both  properties  we  require  semantic  security  under  a  chosen-ciphertext  attack.  Un¬ 
fortunately,  we  cannot  quite  claim  that  the  scheme  above  satisfies  both  properties. 

OAEP  and  it  variants  are  designed  to  provide  chosen  ciphertext  security  for  RSA 
encryption  in  the  random  oracle  model.  The  protocol  above  provides  chosen  cipher- 
text  security  against  an  attacker  who  is  neither  the  SEM  nor  the  user.  However, 
OAEP  does  not  necessarily  satisfy  properties  (1)  and  (2)  above.  The  problem  is 
that  the  user  can  employ  the  SEM  as  an  RSA  inversion  oracle  until  the  user  is 
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Algorithm:  mRSA . decryption  (executed  by  User  and  SEM) 

(1)  USER:  c  <—  encrypted  message 

(2)  USER:  send  c  to  SEM 

(3)  In  parallel: 

3.1.  SEM: 

(a)  If  USER  revoked  return  (ERROR) 

(b)  PCsem  <—  cdiem  mod  ra; 

(c)  Send  PCs£m  to  USER  Ui 

3.2.  USER 

(a)  PC“  <—  mod  m 

(4)  USER:  w  <—  (PCsern  *  PCU)  mod  rij 

(5)  USER:  OAEP  decode  w.  If  success,  output  m  =  DC0aep(w). 


Fig.  3.  mRSA  Decryption  Algorithm 

revoked.  There  is  no  way  for  the  SEM  to  check  whether  a  partial  decryption  it  gen¬ 
erates  corresponds  to  a  well- formed  plaintext.  However,  as  in  the  previous  section, 
security  can  be  proven  in  a  weaker  model  under  a  strong  assumption  on  RSA.  (A 
detailed  proof  will  be  available  in  the  extended  version  of  this  paper.) 

We  note  that  one  way  to  make  sure  that  the  user  cannot  decrypt  messages  with¬ 
out  the  help  of  the  SEM  would  be  to  use  a  Chosen  Ciphertext  Secure  threshold 
cryptosystem  [Shoup  and  Gennaro  1998;  Canetti  and  Goldwasser  1999].  However, 
this  would  render  the  resulting  scheme  incompatible  with  currently  deployed  en¬ 
cryption  systems  (based  on  PKCS1). 

3.4  Notable  Features 

As  mentioned  earlier,  mRSA  is  only  a  slight  modification  of  the  RSA  cryptosystem. 
However,  at  a  higher  level,  mRSA  affords  some  interesting  features. 

CA-based  Key  Generation.  Recall  that,  in  a  normal  PKI  setting  with  RSA,  a  pri¬ 
vate/public  key-pair  is  always  generated  by  its  intended  owner.  In  mRSA,  a  client’s 
key-pair  is  instead  generated  by  a  CA  or  some  other  trusted  entity.  Nonetheless, 
a  CA  only  generates  client’s  keys  and  does  not  need  to  keep  them.  In  fact,  a  CA 
must  erase  them  to  assure  that  any  successful  future  attack  on  the  CA  does  not 
result  in  client’s  keys  being  compromised.  In  spite  of  that,  having  a  trusted  entity 
that  generates  private  keys  for  a  multitude  of  clients  can  be  viewed  as  a  liability. 
If  CA-based  key  generation  is  undesirable  then  one  can  use  a  protocol  of  [Boneh 
and  Franklin  2001]  to  distributively  generate  an  RSA  key  between  the  SEM  and 
the  user.  The  downside  is  that  this  requires  more  work  than  letting  the  CA  gen¬ 
erate  the  key  and  give  shares  to  the  user  and  SEM.  We  note  that  CA-based  key 
generation  enables  key  escrow  (provided  that  clients’  keys  are  not  erased  after  their 
out-of-band  distribution).  For  example,  if  Alice  is  fired,  her  organization  can  still 
access  Alice’s  encrypted  work-related  data  by  obtaining  her  private  key  from  the 
CA. 

Fast  Revocation.  The  main  point  of  mRSA  is  that  the  revocation  problem  is 
greatly  simplified.  In  order  to  revoke  a  client’s  public  key,  it  suffices  to  notify  that 
client’s  SEM.  Each  SEM  merely  maintains  a  list  of  revoked  clients  which  is  consulted 
upon  every  service  request.  Our  implementation  uses  standard  X.509  Certificate 
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Revocation  Lists  (CRT’s)  for  this  purpose. 

Transparency.  mRSA  is  completely  transparent  to  entities  encrypting  data  for 
mRSA  clients  and  those  verifying  signatures  produced  by  mRSA  clients.  To  them, 
mRSA  appears  indistinguishable  from  standard  RSA.  Furthermore,  mRSA  certifi¬ 
cates  are  identical  to  standard  RSA  certificates.  Thus,  the  SEM  architecture  is 
completely  backwards  compatible  for  the  signature  verifier  and  message  encryptor. 

Coexistence.  mRSA’s  built-in  revocation  approach  can  co-exist  with  the  tradi¬ 
tional,  explicit  revocation  approaches.  For  example,  a  CRL-  or  a  CRT-based  scheme 
can  be  used  in  conjunction  with  mRSA  in  order  to  accommodate  existing  imple¬ 
mentations  that  require  verifiers  (and  encryptors)  to  perform  certificate  revocation 
checks. 

CA  Communication,  in  mRSA,  a  CA  remains  an  off-line  entity.  mRSA  cer¬ 
tificates,  along  with  private  half- keys  are  distributed  to  the  client  and  SEM-s  in 
an  off-line  manner.  This  follows  the  common  certificate  issuance  and  distribution 
paradigm.  In  fact,  in  our  implementation  (Section  6)  there  is  no  need  for  the  CA 
and  the  SEM  to  ever  communicate  directly. 

SEM  Communication.  mRSA  does  not  require  explicit  authentication  between  a 
SEM  and  its  clients.  A  client  implicitly  authenticates  a  SEM  by  verifying  its  own 
signature  (or  decryption)  as  described  in  Sections  3.2  and  3.3.  These  signature  and 
encryption  verification  steps  assure  the  client  of  the  validity  of  SEM’s  replies.  Al¬ 
though  authentication  of  a  client  to  a  SEM  is  not  required  for  the  security  of  mRSA 
itself,  it  is  needed  for  protection  against  denial-of-service  attacks  on  a  SEM.  This 
can  be  easily  accomplished  with  the  authentication  protocol  described  in  Section  5. 

Semi-trusted  SEM.  The  SEM  cannot  issue  messages  on  behalf  of  unrevoked  users 
nor  can  it  decrypt  messages  intended  for  unrevoked  users.  The  worst-case  damage 
caused  by  a  compromise  at  the  SEM  is  that  users  who  were  previously  revoked 
can  become  unrevoked.  This  is  similar  to  a  compromise  at  a  standard  Revocation 
Authority  which  would  enable  the  attacker  to  unrevoke  revoked  users. 

4.  ARCHITECTURE 

The  overall  architecture  is  made  up  of  three  components:  CA,  SEM,  and  clients.  A 
typical  organizational  setup  involves  one  CA,  a  small  set  of  SEM-s  and  a  multitude 
of  clients.  A  CA  governs  a  small  number  of  SEM-s.  Each  SEM,  in  turn,  serves  many 
clients.  (In  Section  5  we  show  how  a  single  client  can  be  supported  by  multiple 
SEM-s.)  The  assignment  of  clients  to  SEM-s  is  assumed  to  be  handled  off-line  by  a 
security  administrator. 

The  CA  component  is  a  simple  add-on  to  the  existing  CA  and  is  thus  still  consid¬ 
ered  an  off-line  entity.  For  each  client,  the  CA  component  takes  care  of  generating 
an  RSA  public  key,  the  corresponding  certificate  and  a  pair  of  half-keys  (one  for 
the  client  and  one  for  the  SEM)  which,  when  combined,  form  the  RSA  private  key. 
The  respective  half-keys  are  then  delivered,  out-of-band,  to  the  interested  parties. 

The  client  component  consists  of  the  client  library  that  provides  the  mRSA  sig¬ 
nature  and  mRSA  decryption  operations.  It  also  handles  the  installation  of  the 
client’s  credentials  at  the  local  host. 
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The  SEM  component  is  the  critical  part  of  the  architecture.  Since  a  single 
SEM  serves  many  clients,  performance,  fault-tolerance  and  physical  security  are 
of  paramount  concern.  The  SEM  component  is  basically  a  daemon  process  that 
processes  requests  from  its  constituent  clients.  For  each  request,  it  consults  its  re¬ 
vocation  list  and  refuses  to  help  sign  (or  decrypt)  for  any  revoked  client.  A  SEM 
can  be  configured  to  operate  in  a  stateful  or  stateless  model.  The  former  involves 
storing  per  client  state  (half-key  and  certificate)  while,  in  the  latter,  no  per  client 
state  is  kept,  however,  some  extra  processing  is  incurred  for  each  client  request. 
The  tradeoff  is  fairly  clear:  per  client  state  and  fast  request  handling  versus  no 
state  and  somewhat  slower  request  handling. 

4.1  Details 

We  now  describe  the  SEM  interaction  in  more  detail.  A  client’s  request  is  initially 
handled  by  the  SEM  controller  which  checks  the  format  of  the  request  packet.  Next, 
the  request  is  passed  on  to  the  client  manager  which  performs  a  revocation  check. 
If  the  requesting  client  is  not  revoked,  the  request  is  handled  depending  on  the  SEM 
state  model.  If  the  SEM  is  stateless,  it  expects  to  find  the  so-called  SEM  bundle 
in  the  request.  This  bundle,  as  discussed  in  more  detail  later,  contains  the  mRSA 
half- key,  dfEM,  encrypted  (for  the  SEM,  using  its  public  key)  and  signed  (by  the 
CA).  The  bundle  also  contains  the  RSA  public  key  certificate  for  the  requesting 
client.  Once  the  bundle  is  verified,  the  request  is  handled  by  either  the  mRSAs;gn  or 
mRSAdecrypt  component.  If  the  SEM  maintains  client  state,  the  bundle  is  expected 
only  in  the  initial  request.  The  same  process  as  above  is  followed,  however,  the 
SEM’s  half-key  and  the  client’s  certificate  are  stored  locally.  In  subsequent  client 
requests,  the  bundle  (if  present)  is  ignored  and  local  state  is  used  instead. 

The  security  administrator  communicates  with  a  SEM  via  the  administrative 
interface.  This  interface  allows  the  administrator  to  manipulate  the  revocation  list 
which,  in  our  implementation  is  a  regular  X.509  CRL.  (The  X.509  format  is  not  a 
requirement;  a  CRL  can  be  represented  in  any  signed  format  as  long  as  it  contains 
a  list  of  revoked  clients’  certificate  serial  numbers.) 

4.2  Implications  of  SEM  Compromise 

Suppose  that  an  attacker  compromises  a  SEM  and  learns  dfem.  This  knowlege  can 
be  used  to  “unrevoke”  already  revoked  clients  or  block  (ignore)  future  revocations. 
In  the  worst  case,  an  attacker  could  neutralize  SEM’s  mandatory  involvement  and 
thus  cause  the  system  to  degrade  to  the  reliance  on  normal  revocation  techniques, 
such  as  CRLs.  However,  we  stress  that  knowledge  of  dfem  alone  does  not  enable 
an  attacker  to  decrypt  or  sign  messages  on  behalf  of  a  client. 

Another  interesting  side-effect  is  the  observation  that  there  is  no  need  to  revoke 
all  clients  public  keys  whose  key  shares  are  exposed  due  to  a  compromised  SEM.  As 
long  as  a  given  client  is  not  malicious  (or  compromised)  its  public  key  can  remain 
the  same.  Specifically,  in  case  of  SEM  compromise,  a  CA  can  simply  generate  a  new 
pair  of  mRSA  private  half- keys  for  a  given  client  using  the  same  RSA  (e,,  di,  Ui) 
setting,  but  with  a  different  SEM.  This  is  possible  because  there  are  many  ways  to 
randomly  “split”  a  given  private  exponent  d  into  two  parts.  More  generally,  since 
each  SEM  client  has  a  distinct  RSA  setting,  even  if  a  number  of  malicious  clients 
collude,  there  is  no  danger  to  other  (non-malicious)  clients. 
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5.  EXTENSIONS 


We  now  briefly  discuss  several  simple  extensions  of  mRSA:  multi-SEM  support, 
mRSA  blind  signatures,  identity-based  mRSA,  and  authentication  of  mRSA  re¬ 
quests. 

Multi-SEM  Support 

Since  each  SEM  serves  many  clients,  a  SEM  failure  -  whether  due  to  malicious  or 
accidental  causes  prevents  all  of  its  clients  from  decrypting  data  and  generating 
signatures.  To  avoid  having  a  single  point  of  failure,  mRSA  can  be  modified  to 
allow  a  single  client  to  use  multiple  SEM-s. 

The  easiest  approach  is  to  physically  replicate  a  SEM.  While  this  helps  with  as¬ 
suring  service  availability  with  respect  to  accidental  (non-malicious)  failures,  repli¬ 
cation  does  not  protect  against  hostile  attacks. 

Another  trivial  solution  is  to  allow  a  client  to  be  served  by  multiple  SEM-s,  each 
with  a  different  mRSA  setting.  This  would  require  the  CA  to  run  the  mRSA 
key  generation  algorithm  t  times  (if  t  is  the  number  of  SEM-s)  for  each  client.  In 
addition  to  the  increased  computational  load  for  the  CA,  this  approach  would  entail 
each  client  having  t  distinct  certificates  or  a  single  certificate  with  t  public  keys. 
The  main  disadvantage  would  be  for  other  users  (be  they  SEM  clients  or  not)  who 
would  have  to  be  aware  of,  and  maintain,  t  public  keys  for  a  given  SEM  client. 

Our  approach  allows  a  SEM  client  to  have  a  single  public  key  and  a  single  certifi¬ 
cate  while  offering  the  flexibility  of  obtaining  service  from  any  of  a  set  of  SEM-s.  At 
the  same  time,  each  SEM  maintains  a  different  mRSA  half-key  for  a  given  client. 
Thus,  if  any  number  of  SEM-s(who  support  a  given  client)  collude,  they  are  unable 
to  impersonate  that  client,  i.e. ,  unable  to  compute  the  client’s  half-key.  Multi-SEM 
support  involves  making  a  slight  change  to  the  mRSA  key  generation  algorithm,  as 
shown  in  Figure  5. 


Algorithm 

i:  mRSA. multi -key  (executed  by  CA) 

Choose  a 

collision-resistant  hash  function  H  :  {0,1}*  — ► 

[1, . . . ,  L\  where 

L  >  1024.  Let  k  (even)  be  the  security  parameter.  Assume  client  Ui 

is  authorized  to  obtain  service  from  {SEMo,  SEMi , . . . ,  SEM 

m  }  • 

(1)  Generate  random  k/ 2-bit  primes:  p,q 

(2)  rii  t- 

-  PiQi 

(3)  e;  A 

^ Hnt ) 

(4)  di  «- 

1/e  mod 

(5)  x  A 

zni  -  {0} 

(6)  For  each  j  E  [0, . . . , m],  construct  a  server  bundle  for  SEMj\ 

dsem  + _  d.  _  H(a,j  SEMj)  mod  <t>(n) 

(7)  SIU 

<—  (ni,x) 

(8)  PI<i 

<—  ( rif.ej ) 

Fig.  4.  mRSA  Key  Generation  for  multiple  SEM-s 

To  co-operate  with  SEMj,  the  client  simply  computes  H (x,SEMj)  as  the  corre¬ 
sponding  mRSA  half- key  for  the  decryption  or  signatures. 
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Blind  Signatures  with  mRSA 

The  concept  of  blind  signatures  was  introduced  by  Chaum  in  [Chaum  1983]  and 
[Chaum  1985].  They  were  originally  intended  for  use  in  e-cash  schemes  where 
a  bank  (the  actual  signer)  helps  a  client  generate  a  signature  on  a  message  m, 
without  knowledge  of  either  m  or  the  final  signature. 

mRSA  can  be  easily  extended  to  produce  blind  signatures.  Suppose  U%  wants  to 
generate  a  blind  signature  on  a  message  m.  Ui  first  masks  m  by  choosing  r  €tz  Z* . 
and  setting  m'  =  rei EC (h(m))  mod  n».  Then  Ui  sends  a  signature  request  on  in' 
to  SEM  and,  in  the  meantime,  computes  PSU  =  m'di  mod  n».  SEM  operates  in 
the  same  way  as  in  normal  mRSA.  When  Ui  receives  PSsem ,  it  simply  obtains 
PS  =  r~l  *  PSU  *  PSsem  =  EC{h(m))di  mod  m . 

Identity-based  mRSA 

The  concept  of  identity-based  cryptosystems  was  introduced  by  Shamir  in  [Shamir 
1985].  In  an  identity-based  cryptosystem,  all  clients  in  an  organization  share  a 
common  cryptographic  setting  and  their  public  keys  are  efficiently  derived  from 
their  identities  using  a  public  algorithm.  Therefore,  personal  public  key  certificates 
are  not  needed,  which  greatly  simplifies  certificate  management  and  reduces  reliance 
on  PKI-s.  Several  identity-based  signature  systems  have  been  developed  in  the  past, 
e.g.,  [Guillou  and  Quisquater  1988].  The  first  practical  identity-based  encryption 
system  was  recently  proposed  by  Boneh  and  Franklin  in  [Boneh  and  Franklin  2003] . 
However,  no  RSA-compatible  identity-based  cryptosystem  has  been  developed  thus 
far. 

It  turns  out  that  mRSA  can  be  modified  to  obtain  an  identity-based  RSA  variant 
(for  both  encryption  and  signatures)  where  clients  share  a  common  RSA  modulus 
n  and  a  client’s  public  key  e*  is  derived  from  its  identity.  We  briefly  outline  it  here, 
however,  a  more  detailed  description  can  be  found  in  [Ding  and  Tsudik  2003]. 

In  this  variant,  only  the  CA  knows  the  factorization  of  the  common  modulus  n. 
For  each  client  Ui,  CA  computes  a  unique  public  key  e,  from  the  Ui  s  identity  (e.g., 
its  email  addresses)  using  a  collision-resistant  hash  function.  Then,  a  CA  computes 
the  corresponding  di  =  e~l  mod  4>{n).  The  private  key  splitting  as  well  as  the 
signature  and  decryption  are  all  the  same  as  in  mRSA,  except  that  a  CA  does  not 
issue  an  individual  public  key  certificates  to  each  client.  Instead,  a  CA  issues  a 
site-wide  (or  organization-wide)  attribute  certificate,  which  includes,  among  other 
things,  the  common  modulus  n. 

It  is  well-known  that  sharing  a  common  modulus  among  multiple  clients  in  plain 
RSA  is  utterly  insecure,  since  knowledge  of  a  single  RSA  public/private  key-pair 
can  be  used  to  factor  the  modulus  and  obtain  others’  private  keys.  However,  this 
is  not  an  issue  in  identity-based  mRSA  since  no  client  possesses  an  entire  private 
key.  However,  collusion  of  a  SEM  and  a  single  malicious  client  will  result  in  a 
compromise  of  all  clients  of  that  SEM.  Thus,  a  SEM  in  identity-based  mRSA  must 
be  a  fully  trusted  entity. 

Authenticated  mRSA 

As  discussed  earlier,  authentication  of  mRSA  client  requests  can  provide  protec¬ 
tion  against  denial-of-service  (DoS)  attacks  on  a  SEM.  To  address  DoS  attacks,  we 
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can  modify  both  mRSA  signature  and  decryption  protocols  to  allow  the  SEM  to 
authenticate  incoming  requests.  For  example,  a  client  Ui  can  use  its  half-key  df  to 
sign  each  SEM  -bound  request  message.  (This  can  be  done,  for  example,  by  having 
the  client  generate  a  partial  signature  on  each  request  that  is  then  verified  by  the 
SEM,  much  in  the  same  manner  that  a  client  verifies  SEM’s  reply  in  Step  5  of  Figure 
2-) 

Although  this  method  is  simple  and  requires  no  additional  set  up  costs,  it  does 
not  really  prevent  DoS  attacks,  since  a  SEM  would  need  to  perform  two  modular  ex¬ 
ponentiations  to  authenticate  each  request.  A  simpler,  more  cost-effective  approach 
is  to  use  a  MAC  or  keyed  hash,  e.g.,  HMAC  [Bellare  et  al.  1997],  to  authenticate 
client  requests.  Of  course,  this  would  require  a  shared  secret  key  between  a  SEM 
and  each  client.  A  CA  could  help  in  the  generation  and  distribution  of  such  shared 
secrets  at  the  time  of  mRSA  key  generation.  Yet  another  alternative  is  to  rely  on 
more  general  encapsulation  techniques,  such  as  SSL,  to  provide  a  secure  channel 
for  communication  between  SEM-s  and  clients. 

6.  IMPLEMENTATION 

We  implemented  the  entire  SEM  architecture  for  the  purposes  of  experimentation 
and  validation.  The  reference  implementation  is  publicly  available  at  http :  / / 
sconce.ics.uci.edu/sucses.  Following  the  SEM  architecture  described  earlier, 
the  implementation  is  composed  of  three  parts: 

(1)  CA  and  Admin  Utilities: 

includes  certificate  issuance  and  revocation  interface. 

(2)  SEM  daemon: 

SEM  architecture  as  described  in  Section  4 

(3)  Client  libraries: 

mRSA  client  functions  accessible  via  an  API. 

The  reference  implementation  uses  the  popular  OpenSSL  library  as  the  low-level 
cryptographic  platform.  OpenSSL  incorporates  a  multitude  of  cryptographic  func¬ 
tions  and  large-number  arithmetic  primitives.  In  addition  to  being  efficient  and 
available  on  many  common  hardware  and  software  platforms,  OpenSSL  adheres  to 
the  common  PKCS  standards  and  is  in  the  public  domain. 

The  SEM  daemon  and  the  C A/ Admin  utilities  are  implemented  on  Linux  and 
Unix  while  the  client  libraries  are  available  on  both  Linux  and  Windows  platforms. 

In  the  initialization  phase,  CA  utilities  are  used  to  set  up  the  RSA  public  key- 
pair  for  each  client  (client).  The  set  up  process  follows  the  description  in  Section  3. 
Once  the  mRSA  parameters  are  generated,  two  structures  are  exported:  1)  server  or 
SEM  bundle,  which  includes  the  SEM’s  half-key  dfEM,  and  2)  client  bundle,  which 
includes  df,  the  new  certificate,  and  the  entire  server  bundle  if  SEM  is  a  stateless 
server. 

A  SEM  bundle  is  a  PKCS7  envelope.  It  contains  dfEM  encrypted  with  the  SEM’s 
public  key  and  signed  by  the  CA.  The  client  bundle  is  in  PKCS12  format  integrating 
the  password  privacy  and  public  key  integrity  modes:  it  is  signed  by  the  CA  and 
encrypted  with  the  client-supplied  key  which  can  be  derived  from  a  password  or  a 
passphrase.  (Note  that  a  client  cannot  be  assumed  to  have  a  pre-existing  public 
key.) 


31 


After  issuance,  the  client  bundle  is  distributed  out-of-band  to  the  appropriate 
client.  Before  attempting  any  mRSA  transactions,  the  client  must  first  decrypt 
the  bundle  with  its  key  and  verify  the  CA’s  signature.  Finally,  the  client’s  new 
certificate,  the  SEM  bundle  and  half- key  are  extracted  and  stored  locally. 

To  sign  or  decrypt  a  message,  the  client  starts  with  sending  a  mRSA  request  with 
the  SEM  bundle  piggybacked.  The  SEM  processes  the  request  and  the  bundle  con¬ 
tained  therein  as  described  in  Section  4.  (Recall  that  the  SEM  bundle  is  processed 
based  on  the  state  model  of  the  particular  SEM.)  If  SEM  can  successfully  open  its 
bundle,  it  checks  the  whether  the  client’s  certificate  is  on  the  revocation  list.  If  not, 
SEM  follows  the  protocol  and  returns  a  corresponding  reply  to  the  client. 

6.1  Email  client  plug-in 

To  further  demonstrate  the  ease  of  use  and  practicality  of  the  SEM  architecture, 
we  implemented  plug-ins  for  both  Eudora  email  reader  and  Outlook  2000  email 
client.  When  sending  signed  email,  the  plug-in  reads  the  client  bundle  described 
in  the  previous  section.  It  obtains  the  SEM  address  from  the  bundle  and  then 
communicates  with  the  SEM  to  sign  the  email.  The  resulting  signed  email  can  be 
verified  using  any  S/MIME  capable  email  client  such  as  Microsoft  Outlook.  In  other 
words,  the  email  recipient  is  oblivious  to  the  fact  that  a  SEM  is  used  to  control 
the  sender’s  signing  capabilities.  When  reading  an  encrypted  email,  the  plug-in 
automatically  loads  the  client  bundle  and  decrypts  the  message  by  cooperating 
with  SEM.  For  the  sender,  all  S/MIME  capable  email  composers  can  encrypt  email 
for  mRSA  clients  without  any  changes. 

6.2  mRSA  Email  Proxy 

An  alternative  way  to  use  mRSA  is  through  an  mRSA-enabled  email  proxy.  A 
proxy  resides  on  the  client’s  local  host,  runs  in  the  background  (as  a  daemon  on 
Unix  or  a  TSR  program  on  Windows)  and  relays  email  messages  between  the  local 
host  and  a  remote  SMTP  server.  An  outbound  email  message,  if  requested,  can  be 
processed  by  the  mRSA  proxy  using  the  same  mRSA  protocol  as  in  the  plug-in.  For 
inbound  email,  the  proxy  can  decrypt  or  verify  signatures,  if  necessary.  The  main 
benefit  of  using  a  proxy  is  that  it  provides  a  single  unified  interface  to  the  end-client 
and  all  email  applications.  This  obviates  the  need  to  customize  or  modify  email 
clients  and  offers  a  greater  degree  of  transparency  as  well  as  ease  of  installation  and 
configuration. 

7.  EXPERIMENTAL  RESULTS 

We  conducted  a  number  of  experiments  in  order  to  evaluate  the  efficiency  of  the 
SEM  architecture  and  our  implementation. 

We  ran  the  SEM  daemon  on  a  Linux  PC  equipped  with  an  800  MHz  Pentium  III 
processor.  Two  different  clients  were  used.  The  fast  client  was  on  another  Linux 
PC  with  a  930  MHz  Pentium  III.  Both  SEM  and  fast  client  PC-s  had  256M  of  RAM. 
The  slow  client  was  on  a  Linux  PC  with  466  MHz  Pentium  II  and  128M  of  RAM. 
Although  an  800  MHz  processor  is  not  exactly  state-of-the-art,  we  opted  to  err  on 
the  side  of  safety  and  assume  a  relatively  conservative  (i.e. ,  slow)  SEM  platform.  In 
practice,  a  SEM  might  reside  on  much  faster  hardware  and  is  likely  to  be  assisted 
by  an  RSA  hardware  acceleration  card. 
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Keysize 

(bits) 

Data  Size 
(bytes) 

Comm,  latency 
(ms) 

512 

102 

4.0 

1024 

167 

4.5 

2048 

296 

5.5 

Table  I.  Communication  latency 

Each  experiment  involved  one  thousand  iterations.  All  reported  timings  are  in 
milliseconds  (rounded  to  the  nearest  0.1  ms).  The  SEM  and  client  PCs  were  located 
in  different  sites  interconnected  by  a  high-speed  regional  network.  All  protocol 
messages  are  transmitted  over  UDP. 

Client  RSA  key  (modulus)  sizes  were  varied  among  512,  1024  and  2048  bits. 
(Though  it  is  clear  that  512  is  not  a  realistic  RSA  key  size  any  longer.)  The 
timings  are  only  for  the  mRSA  sign  operation  since  mRSA  decrypt  is  operationally 
almost  identical. 

7.1  Communication  Overhead 

In  order  to  gain  precise  understanding  of  our  results,  we  first  provide  separate  mea¬ 
surements  for  communication  latency  in  mRSA.  Recall  that  both  mRSA  operations 
involve  a  request  from  a  client  followed  by  a  reply  from  a  SEM.  As  mentioned  above, 
the  test  PCs  were  connected  by  a  high-speed  regional  network.  We  measured  com¬ 
munication  latency  by  varying  the  key  size  which  directly  influences  message  sizes. 
The  results  are  shown  in  Table  I  (message  sizes  are  in  bytes).  Latency  is  calculated 
as  the  round-trip  delay  between  the  client  and  the  SEM.  The  numbers  are  identical 
for  both  client  types. 

7.2  Standard  RSA 

As  a  point  of  comparison,  we  initially  timed  the  standard  RSA  sign  operation  in 
OpenSSL  (Version  0.9.6)  with  three  different  key  sizes  on  each  of  our  three  test  PCs. 
The  results  are  shown  in  Tables  II  and  III.  Each  timing  includes  a  message  hash 
computation  followed  by  an  modular  exponentiation.  Table  II  reflects  optimized 
RSA  computation  where  the  Chinese  Remainder  Theorem  (CRT)  is  used  to  speed 
up  exponentiation  (essentially  exponentiations  are  done  modulo  the  prime  factors 
rather  than  modulo  N).  Table  III  reflects  unoptimized  RSA  computation  without 
the  benefit  of  the  CRT.  Taking  advantage  of  the  CRT  requires  knowledge  of  the 
factors  (p  and  q)  of  the  modulus  n.  Recall  that,  in  mRSA,  neither  the  SEM  nor  the 
client  know  the  factorization  of  the  modulus,  hence,  with  regard  to  its  computation 
cost,  mRSA  is  more  akin  to  unoptimized  RSA. 

As  evident  from  the  two  tables,  the  optimized  RSA  performs  a  factor  of  3  to  3.5 
faster  for  the  1024-  and  2048-bit  moduli  than  the  unoptimized  version.  For  512-bit 
keys,  the  difference  is  slightly  less  marked. 

7.3  mRSA  Measurements 

The  mRSA  results  are  obtained  by  measuring  the  time  starting  with  the  message 
hash  computation  by  the  client  (client)  and  ending  with  the  verification  of  the 
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Key-size 

(bits) 

466  MHz  PII 
(slow  client) 

800  MHz  PHI 
(SEM) 

930  MHz  PHI 
(fast  client) 

512 

2.9 

1.4 

1.4 

1024 

14.3 

7.7 

7.2 

2048 

85.7 

49.4 

42.8 

Table  II.  Standard  RSA  (with  CRT)  signature  timings  in  ms. 


Key-size 

(bits) 

466  MHz  PII 
(slow  client) 

800  MHz  PHI 
(SEM) 

930  MHz  PHI 
(fast  client) 

512 

6.9 

4.0 

3.4 

1024 

43.1 

24.8 

21.2 

2048 

297.7 

169.2 

144.7 

Table  III.  Standard  RSA  (without  CRT)  signature  timings  in  ms. 


Key-size 

(bits) 

466  MHz  PII 
(slow  client) 

930  MHz  PHI 
(fast  client) 

512 

8.0 

9.9 

1024 

45.6 

31.2 

2048 

335.6 

178.3 

Table  IV.  mRSA  signature  timings  in  ms. 


signature  by  the  client.  The  measurements  are  illustrated  in  Table  IV. 

It  comes  as  no  surprise  that  the  numbers  for  the  slow  client  in  Table  IV  are  very 
close  to  the  unoptimized  RSA  measurements  in  Table  III.  This  is  because  the  time 
for  an  mRSA  operation  is  determined  solely  by  the  client  for  1024-  and  2048-  bit 
keys.  With  a  512-bit  key,  the  slow  client  is  fast  enough  to  compute  its  PSU  in 
6.9ms.  This  is  still  under  8.0ms  (the  sum  of  4?ns  round-trip  delay  and  4?tts  RSA 
operation  at  the  SEM). 

The  situation  is  very  different  with  a  fast  client.  Here,  for  all  key  sizes,  the  timing 
is  determined  by  the  sum  of  the  round-trip  client-SEM  packet  delay  and  the  service 
time  at  the  SEM.  For  instance,  178.3ms  (clocked  for  2048-bit  keys)  is  very  close  to 
174.7?7is  which  is  the  sum  of  5.5ms  communication  delay  and  169.2ms  unoptimized 
RSA  operation  at  the  SEM. 

All  of  the  above  measurements  were  taken  with  the  SEM  operating  in  a  stateful 
mode.  In  a  stateless  mode,  SEM  incurs  further  overhead  due  to  the  processing 
of  the  SEM  bundle  for  each  incoming  request.  This  includes  decryption  of  the 
bundle  and  verification  of  the  CA’s  signature  found  inside.  To  get  an  idea  of  the 
mRSA  overhead  with  a  stateless  SEM,  we  conclude  the  experiments  with  Table  V 
showing  the  bundle  processing  overhead.  Only  1024-  and  2048-bit  SEM  key  size 
was  considered.  (512-bit  keys  are  certainly  inappropriate  for  a  SEM.)  The  CA  key 
size  was  constant  at  1024  bits. 


34 


SEM  key  size 

Bundle  overhead 

1024 

8.1 

2048 

50.3 

Table  V.  Bundle  overhead  in  mRSA  with  a  SEM  in  a  stateless  mode  (in  millisec¬ 
onds). 


8.  RELATED  WORK 

Our  system  is  constructed  on  top  of  a  2-out-of-2  threshold  RSA  algorithm,  for 
the  purpose  of  instant  certificate  revocation.  In  the  following,  we  compare  it  with 
others’  work  with  related  functionality  as  well  as  those  with  similar  cryptographic 
setting. 

8.1  Current  Revocation  Techniques 

Certificate  revocation  is  a  well-recognized  problem  in  all  current  PKI-s.  Several 
proposals  attempt  to  address  this  problem.  We  briefly  review  these  proposals  and 
compare  them  to  the  SEM  architecture.  For  each,  we  describe  how  it  applies  to  sig¬ 
natures  and  encryption.  We  refer  to  the  entity  validating  and  revoking  certificates 
as  the  Validation  Authority  (VA).  Typically,  a  VA  and  a  CA  are  one  and  the  same. 
However,  in  some  cases  (such  as  OCSP)  these  are  separate  entities. 

CRLs  and  A-CRLs:  these  are  the  most  common  ways  to  handle  certificate  revo¬ 
cation.  The  Validation  Authority  (VA)  periodically  posts  a  signed  list  (or  another 
data  structure)  containing  all  revoked  certificates.  Such  lists  are  placed  on  desig¬ 
nated  servers,  called  CRL  Distribution  Points.  Since  a  list  can  get  quite  long,  a  VA 
may  post  a  signed  A-CRL  which  only  contains  the  list  of  certificates  revoked  since 
the  last  CRL  was  issued.  In  the  context  of  encrypted  email,  at  the  time  email  is 
sent,  the  sender  checks  if  the  receiver’s  certificate  is  included  in  the  latest  CRL.  To 
verify  a  signature  on  a  signed  email  message,  the  verifier  first  checks  if  (at  present 
time)  the  signer’s  certificate  is  included  in  the  latest  CRL. 

OCSP:  the  Online  Certificate  Status  Protocol  (OCSP)  [Myers  et  al.  1999]  avoids 
the  generation  and  distribution  of  potentially  long  CRLs  and  provides  more  timely 
revocation  information.  To  validate  a  certificate  in  OCSP,  the  client  sends  a  cer¬ 
tificate  status  request  to  the  VA.  The  VA  sends  back  a  signed  response  indicating 
the  status  (revoked,  valid,  unknown)  of  the  specified  certificate. 

We  remark  that  the  current  OCSP  protocol  prevents  one  from  implementing  bind¬ 
ing  signature  semantics:  it  is  impossible  to  ask  an  OCSP  responder  whether  a 
certificate  was  valid  at  some  time  in  the  past.  Hopefully,  this  will  be  corrected 
in  future  versions  of  OCSP.  One  could  potentially  abuse  the  OCSP  protocol  and 
provide  binding  semantics  as  follows.  To  sign  a  message,  the  signer  generates  the 
signature,  and  also  sends  an  OCSP  query  to  the  VA.  The  VA  responds  with  a  signed 
message  saying  that  the  certificate  is  currently  valid.  The  signer  appends  both  the 
signature  and  the  response  from  the  VA  to  the  message.  To  verify  the  signature, 
the  verifier  checks  the  VA’s  signature  on  the  validation  response.  The  response 
from  the  VA  provides  a  proof  that  the  signer’s  certificate  is  currently  valid.  This 
method  reduces  the  load  on  the  VA:  it  is  not  necessary  to  contact  the  VA  every 
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time  a  signature  is  verified.  Unfortunately,  there  is  currently  no  infrastructure  to 
support  this  mechanism. 

Certificate  Revocation  Trees:  Kocher  suggested  an  improvement  over  OCSP  [Kocher 
1998].  Since  the  VA  is  a  global  service  it  must  be  sufficiently  replicated  in  order 
to  handle  the  load  of  all  the  validation  queries.  This  means  the  VA’s  signature  key 
must  be  replicated  across  many  servers  which  is  either  insecure  or  expensive  (VA 
servers  typically  use  tamper-resistance  to  protect  the  VA’s  signing  key).  Kocher’s 
idea  is  to  have  a  single  highly  secure  VA  periodically  post  a  signed  CRL-like  data 
structure  to  many  insecure  VA  servers.  Users  then  query  these  insecure  VA  servers. 

The  data  structure  proposed  by  Kocher  is  a  hash  tree  where  the  leaves  are  the 
currently  revoked  certificates  sorted  by  serial  number  (lowest  serial  number  is  the 
left  most  leaf  and  the  highest  serial  number  is  the  right  most  leaf).  The  root  of  the 
hash  tree  is  signed  by  the  VA.  This  hash  tree  data  structure  is  called  a  Certificate 
Revocation  Tree  (CRT). 

When  a  client  wishes  to  validate  a  certificate  CERT  she  issues  a  query  to  the  closest 
VA  server.  Any  insecure  VA  can  produce  a  convincing  proof  that  CERT  is  (or  is 
not)  on  the  CRT.  If  n  certificates  are  currently  revoked,  the  length  of  the  proof  is 
O(logn).  In  contrast,  the  length  of  the  validity  proof  in  OCSP  is  0(1). 

Skip-lists  and  2-3  trees:  One  problem  with  CRT-s  is  that,  each  time  a  certificate 
is  revoked,  the  whole  CRT  must  be  recomputed  and  distributed  in  its  entirety  to  all 
VA  servers.  A  data  structure  allowing  for  dynamic  updates  would  solve  this  problem 
since  a  secure  VA  would  only  need  to  send  small  updates  to  the  data  structure  along 
with  a  signature  on  the  new  root  of  the  structure.  Both  2-3  trees  proposed  by  Naor 
and  Nissim  [Naor  and  Nissim  2000]  and  skip-lists  proposed  by  Goodrich  [Goodrich 
et  al.  2001]  are  natural  and  efficient  for  this  purpose.  Additional  data  structures 
were  proposed  in  [Aiello  et  al.  1998].  When  a  total  of  n  certificates  are  already 
revoked  and  k  new  certificates  must  be  revoked  during  the  current  time  period,  the 
size  of  the  update  message  to  the  VA  servers  is  O(fclogn)  (as  opposed  to  O(n)  with 
CRT’s).  The  proof  of  certificate’s  validity  is  0(log?r),  same  as  with  CRTs. 

A  note  on  timestamping.  Binding  signature  semantics  (Section  2.2)  for  signature 
verification  states  that  a  signature  is  considered  valid  if  the  key  used  to  generate 
the  signature  was  valid  at  the  time  of  signature  generation.  Consequently,  a  verifier 
must  establish  exactly  when  a  signature  was  generated.  Hence,  when  signing  a 
message,  the  signer  must  interact  with  a  trusted  timestamping  service  to  obtain  a 
trusted  timestamp  and  a  signature  over  the  client’s  (signed)  message.  This  proves 
to  any  verifier  that  a  signature  was  generated  at  a  specific  time.  All  the  techniques 
discussed  above  require  a  signature  to  contain  a  trusted  timestamp  indicating  when 
a  signature  was  issued.  There  is  no  need  for  a  trusted  time  service  to  implement 
binding  signature  semantics  with  the  SEM  architecture.  This  is  because  a  SEM 
can  be  used  to  provide  a  secure  time-stamping  service  as  part  of  its  mandatory 
involvement  in  each  client’s  signature. 

8.2  Two-party  RSA 

Several  other  research  results  developed  schemes  similar  to  the  SEM  architecture 
although  in  different  security  domains.  Among  them,  Yaksha  [Ganesan  1996]  and 
S-RSA  [MacKenzie  and  Reiter  2001b;  2001a]  are  the  schemes  conceptually  closest 
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to  ours.  Both  Yaksha  and  S-RSA  involve  2-party  RSA  function  sharing  where 
clients  do  not  possess  complete  RSA  private  keys  and  rely  on  an  on-line  server  to 
perform  certain  private  key  operations. 

The  Yaksha  system  is  a  reusable  security  infrastructure  which  includes  key  ex¬ 
change  and  key  escrow.  It  allows  a  legitimate  authority  to  recover  clients’  short-term 
session  keys  without  knowing  their  long-term  private  keys.  The  client  and  the  Yak¬ 
sha  server  separately  hold  two  shares  such  that  their  product  forms  a  complete  RSA 
private  key  for  the  client.  When  a  Yaksha  server  receives  a  request  for  generating 
a  session  key,  it  chooses  the  key  at  random,  encrypts  it  with  the  client’s  public  key 
and  decrypts  it  partially  with  the  corresponding  key  share  so  that  the  result  can 
be  decrypted  by  the  client  using  the  other  share. 

Compared  with  our  scheme,  Yaksha  is  more  expensive.  A  Yaksha  client  is  unable 
to  perform  its  local  computation  before  it  receives  the  server’s  result,  whereas,  the 
client’s  and  SEM's  computations  in  our  scheme  are  executed  concurrently.  Also,  a 
Yaksha  server  is  a  fully  trusted  entity  and  its  compromise  completely  breaks  the 
system  security.  In  contrast,  a  SEM  is  only  partially  trusted;  its  compromise  can 
only  impair  the  intended  service.  Furthermore,  a  Yaksha  server  is  a  single  point  of 
failure  and  not  scalable  in  that  it  serves  for  all  users  in  the  system  .  Our  scheme 
allows  multiple  SEM-s,  each  serving  (possibly  overlapping)  subsets  of  clients. 

Another  related  result,  S-RSA,  is  due  to  MacKenzie  and  Reiter  [MacKenzie  and 
Reiter  2001b;  2001a].  It  aims  to  safeguard  password-protected  private  keys  on 
a  captured  networked  device  from  offline  dictionary  attacks.  In  this  scheme,  the 
client’s  share  is  derived  from  its  password;  the  server’s  share  is  contained  in  a  token 
encrypted  with  the  server’s  public  key  and  stored  in  the  device.  The  sum  of  the 
two  shares  forms  the  client’s  private  RSA  key.  When  needed,  the  encrypted  token 
is  sent  to  the  server  which  extracts  the  key  share  and  helps  the  client  to  issue 
a  signature.  The  client  is  also  able  to  notify  the  server  to  disable  its  key  share 
by  revealing  certain  secret  information.  Although  the  underlying  cryptographic 
algorithms  are  similar  to  ours,  the  goals  are  fundamentally  different:  we  focus  on 
fine-grained  control  and  fast  revocation  while  S-RSA  aims  to  protect  networked 
devices. 

Many  other  two-party  schemes  have  been  proposed  in  the  literature.  For  example, 
Boneh  and  Franklin  [Boneh  and  Franklin  2001]  showed  how  to  share  the  RSA  key 
generation  function  between  two  parties.  Nicolosi,  et  al.  [Nicolosi  et  al.  2003] 
designed  a  proactive  two-party  Schnorr  signature  scheme.  MacKenzie  and  Reiter 
[MacKenzie  and  Reiter  2001c]  developed  a  provable  secure  two-party  DSA  signature 
scheme.  However,  none  of  these  schemes  are  used  in  the  content  of  revocation  of 
security  privileges. 

9.  SUMMARY 

We  described  a  new  approach  to  certificate  revocation  and  fine-grained  control  over 
security  capabilities.  Rather  than  revoking  the  client’s  certificate  our  approach 
revokes  the  client’s  ability  to  perform  cryptographic  operations  such  as  signature 
generation  and  decryption.  This  approach  has  several  advantages  over  traditional 
certificate  revocation  techniques:  (1)  revocation  is  fast  -  when  its  certificate  is  re¬ 
voked,  the  client  can  no  longer  decrypt  or  sign  messages,  (2)  with  binding  signature 
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semantics,  there  is  no  need  to  validate  the  signer’s  certificate  as  part  of  signature 
verification,  and  (3)  our  revocation  technique  is  transparent  to  the  peers  since  it 
uses  standard  RSA  signature  and  encryption  formats. 

We  implemented  the  SEM  architecture  for  experimentation  purposes.  Our  mea¬ 
surements  show  that  signature  and  decryption  times  are  not  significantly  higher 
from  the  client’s  perspective.  Therefore,  we  believe  the  SEM  architecture  is  ap¬ 
propriate  for  small-  to  medium-sized  organizations  where  tight  control  of  security 
capabilities  is  desired.  The  SEM  architecture  is  clearly  not  appropriate  for  the 
global  Internet  or  for  educational  campus-like  environments. 
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Abstract.  Identity-based  public  key  encryption  facilitates  easy  introduction  of 
public  key  cryptography  by  allowing  an  entity’s  public  key  to  be  derived  front 
an  arbitrary  identification  value,  such  as  name  or  entail  address.  The  main  prac¬ 
tical  benefit  of  identity-based  cryptography  is  in  greatly  reducing  the  need  for, 
and  reliance  on,  public  key  certificates.  Although  some  interesting  identity-based 
techniques  have  been  developed  in  the  past,  none  are  compatible  with  popular 
public  key  encryption  algorithms  (such  as  El  Gamal  and  RSA).  This  limits  the 
utility  of  identity-based  cryptography  as  a  transitional  step  to  full-blown  pub¬ 
lic  key  cryptography.  Furthermore,  it  is  fundamentally  difficult  to  reconcile  fine¬ 
grained  revocation  with  identity-based  cryptography. 

Mediated  RSA  (mRSA)  [9]  is  a  simple  and  practical  method  of  splitting  a  RSA 
private  key  between  the  user  and  a  Security  Mediator  (SEM).  Neither  the  user 
nor  the  SEM  can  cheat  one  another  since  each  cryptographic  operation  (signature 
or  decryption)  involves  both  parties.  mRSA  allows  fast  and  fine-grained  control 
of  users’  security  privileges.  However,  mRSA  still  relies  on  conventional  public 
key  certificates  to  store  and  communicate  public  keys.  In  this  paper,  we  present 
IB-mRSA,  a  simple  variant  of  mRSA  that  combines  identity-based  and  mediated 
cryptography.  Under  the  random  oracle  model,  IB-niRS  A  with  OAEP[7]  is  shown 
as  secure  (against  adaptive  chosen  ciphertext  attack)  as  standard  RSA  with  OAER 
Furthermore,  IB-mRSA  is  simple,  practical,  and  compatible  with  current  public 
key  infrastructures. 

Keywords:  Identity-based  Encryption,  Mediated  RSA,  Revocation 


1  Introduction 

In  a  typical  public  key  infrastructure  (PKI)  setting,  a  user’s  public  key  is  explicitly  en¬ 
coded  in  a  public  key  certificate  which  is,  essentially,  a  binding  between  the  certificate 
holder’s  identity  and  the  claimed  public  key.  This  common  model  requires  universal 
trust  in  certificate  issuers  (Certification  Authorities  or  CAs).  It  has  some  well-known 
and  bothersome  side-effects  such  as  the  need  for  cross-domain  trust  and  certificate  re¬ 
vocation.  The  main  problem,  however,  is  the  basic  assumption  that  all  certificates  are 
public,  ubiquitous  and,  hence,  readily  available  to  anyone.  We  observe  that  this  assump¬ 
tion  is  not  always  realistic,  especially,  in  wireless  (or  any  fault-prone)  networks  where 
connectivity  is  sporadic. 
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In  contrast,  identity-based  cryptography  changes  the  nature  of  obtaining  public  keys 
by  constructing  a  one-to-one  mapping  between  identities  and  public  keys.  Identity- 
based  cryptography  thus  greatly  reduces  the  need  for,  and  reliance  on,  public  key  cer¬ 
tificates  and  certification  authorities.  In  general,  identity-based  encryption  and  identity- 
based  signatures  are  useful  cryptographic  tools  that  facilitate  easy  introduction  of,  and/or 
conversion  to,  public  key  cryptography  by  allowing  a  public  key  to  be  derived  from  ar¬ 
bitrary  identification  values  such  as  email  addresses  or  phone  numbers.  At  the  same 
time,  identity-based  methods  greatly  simplify  key  management  since  they  reduce  both: 
the  need  for,  and,  the  number  of,  public  key  certificates. 

The  concept  of  identity-based  public  encryption  was  first  proposed  by  Shamir[20]  in 
1984.  For  the  following  16  years  the  progress  in  this  area  has  been  rather  slow.  However, 
recently,  Boneh  and  Franklin  developed  an  elegant  Identity-Based  Encryption  system 
(BF-IBE)  based  on  Weil  Pairing  on  elliptic  curves  [10].  BF-IBE  represents  a  significant 
advance  in  cryptography. 

Nevertheless,  an  identity-based  RSA  variant  has  remained  elusive  for  the  simple 
reason  that  an  RSA  modulus  n  (a  product  of  two  large  primes)  can  not  be  safely 
shared  among  multiple  users.  Another  notable  drawback  of  current  identity-based  cryp¬ 
tographic  methods  is  lack  of  support  for  fine-grained  revocation.  Revocation  is  typi¬ 
cally  done  via  Certificate  Revocation  Lists  (CRLs)  or  similar  structures.  However,  IBE 
aims  to  simplify  certificate  management  by  deriving  public  keys  from  identities,  which 
makes  it  difficult  to  control  users’  security  privileges. 

In  this  paper,  we  propose  a  simple  identity-based  cryptosystem  developed  atop  some 
Mediated  RSA  (mRSA)  by  Boneh,  et  al.  [9].  mRSA  is  a  practical  and  RSA-compatible 
method  of  splitting  an  RSA  private  key  between  the  user  and  the  security  mediator, 
called  a  SEM.  Neither  the  user  nor  the  SEM  knows  the  factorization  of  the  RSA  modu¬ 
lus  and  neither  can  decrypt/sign  message  without  the  other’s  help.  By  virtue  of  requiring 
the  user  to  contact  its  SEM  for  each  decryption  and/or  signature  operation,  mRSA  pro¬ 
vides  fast  and  fine-grained  revocation  of  users’  security  privileges. 

Built  on  top  of  mRSA,  IB-mRSA  blends  the  features  of  identity-based  and  mediated 
cryptography  and  also  offers  some  practical  benefits. 1  Like  mRSA,  it  is  fully  compatible 
with  plain  RSA.  With  the  exception  of  the  identity-to-public-key  mapping,  it  requires  no 
special  software  for  communicating  parties.  IB-mRSA  also  allows  optional  public  key 
certificates  which  facilitates  easy  transition  to  a  conventional  PKI.  More  generally,  IB- 
mRSA  can  be  viewed  as  a  simple  and  practical  technique  inter-operable  with  common 
modern  PKIs.  At  the  same  time,  IB-mRSA  offers  security  comparable  to  that  of  RSA, 
provided  that  a  SEM  is  not  compromised.  Specifically,  it  can  be  shown  that,  in  the 
random  oracle  model,  IB-mRSA  with  OAEP[7]  is  as  secure  -  against  adaptive  chosen 
ciphertext  attacks  -  as  RSA  with  OAEP 

The  rest  of  the  paper  is  organized  as  follows.  The  next  section  gives  a  detailed 
description  of  IB-mRSA.  The  security  analysis  is  presented  in  Section  3  and  the  per¬ 
formance  analysis  -  in  Section  4.  In  Section  5,  IB-mRSA  is  compared  with  Boneh- 
Franklin’s  IBE.  Finally,  a  brief  description  of  the  implementation  is  presented  in  the 
last  section.  Some  further  security  details  can  be  found  in  the  Appendix. 


1  A  very  sketchy  version  of  IB-mRSA  was  first  presented  in  [8]. 


41 


2  Identity-Based  mRSA 


The  main  feature  of  identity-based  encryption  is  the  sender’s  ability  to  encrypt  messages 
using  the  public  key  derived  from  the  receiver’s  identity  and  other  public  information. 
The  identity  can  be  the  receiver’s  email  address,  user  id  or  any  value  unique  to  the 
receiver;  essentially,  an  arbitrary  string.  To  compute  the  encryption  key,  an  efficient 
(and  public)  mapping  function  ICQ  must  be  set  beforehand.  This  function  must  be  a 
one-to-one  mapping  from  identity  strings  to  public  keys. 

The  basic  idea  behind  identity-based  mRSA  is  the  use  of  a  single  common  RSA 
modulus  n  for  all  users  within  a  system  (or  domain).  This  modulus  is  public  and  con¬ 
tained  in  a  system-wide  certificate  issued,  as  usual,  by  some  Certificate  Authority  (CA). 
To  encrypt  a  message  for  a  certain  recipient  (Bob),  the  sender  (Alice)  first  computes 
e-Bob  —  ICQ  {ID  Bob)  where  ID  Bob  is  the  recipient’s  identity  value,  such  as  Bob’s  email 
address.  Thereafter,  the  pair  ( esob >  n)  is  treated  as  a  plain  RSA  public  key  and  normal 
RSA  encryption  is  performed.  On  Bob’s  side,  the  decryption  process  is  identical  to  that 
of  mRSA. 

We  stress  that  using  the  same  modulus  by  multiple  users  in  a  normal  RSA  setting 
is  utterly  insecure.  It  is  subject  to  a  trivial  attack  whereby  anyone  -  utilizing  one’s 
knowledge  of  a  single  key-pair  -  can  simply  factor  the  modulus  and  compute  the  other 
user’s  private  key.  However,  in  the  present  context,  we  make  an  important  assumption 
that;  Throughout  the  lifetime  of  the  system,  the  adversary  is  unable  to  compromise  a 
SEM. 

Obviously,  without  this  assumption,  IB-mRSA  would  offer  no  security  whatsoever: 
a  single  SEM  break-in  coupled  with  the  compromise  of  just  one  user’s  key  share  would 
result  in  the  compromise  of  all  users’  (for  that  SEM)  private  keys.  The  IB-mRSA  as¬ 
sumption  is  slightly  stronger  than  its  mRSA  counterpart.  Recall  that,  in  mRSA,  each 
user  has  a  different  RSA  setting,  i.e.,  a  unique  modulus.  Therefore,  to  compromise  a 
given  user  an  adversary  has  to  break  into  both  the  user  and  its  SEM. 

We  now  turn  to  the  detailed  description  of  the  IB-mRSA  scheme. 

2.1  System  Setting  and  User  Key  Generation 

In  the  following,  we  use  email  addresses  as  unique  identifiers  of  the  public  key  owners 
in  the  system.  However,  as  mentioned  above,  other  identity  types  can  be  used  just  as 
well,  e.g.,  Unix  UIDs,  HTTP  addresses,  physical  addresses  or  even  phone  numbers.  We 
use  the  notation  ID  Alice  to  denote  the  user’s  (Alice)  email  address  that  will  be  used  to 
derive  the  public  exponent. 

In  the  initialization  phase,  a  trusted  party  (CA)  sets  up  the  RSA  modulus  for  all 
users  in  the  same  system  (organization  or  domain).  First,  CA  chooses,  at  random,  two 
large  primes  p'  and  cf  such  that  p  =  2 p'  +  1  and  q  =  2 q'  + 1  are  also  primes,  and  finally 
sets  n  =  pq.  We  note  that,  since  n  is  a  product  of  two  strong  primes,  a  randomly  chosen 
odd  number  in  Zn  has  negligible  probability  of  not  being  relatively  prime  to  fin).  (See 
Section  3  for  further  discussion.)  Hence,  the  mapping  function  ICQ  can  be  quite  trivial. 
(Our  current  implementation  uses  the  popular  M 05  hash  function.) 

The  public  exponent  e  Alice  is  constructed  as  the  output  of  ICQ  {ID  Alice)  repre¬ 
sented  as  a  binary  string  of  the  same  length  as  the  modulus,  with  the  least  significant  bit 
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set.  This  ensures  that  e Alice  is  °dd  and,  with  overwhelming  probability,  relatively  prime 
to  4>(n).  The  complete  IB-mRSA  key  generation  proceeds  as  in  Figure  1. 


Algorithm  IB-mRSA. key  (executed  by  CA) 

Let  k  (even)  be  the  security  parameter 

1.  Generate  random  A: / 2-bit  primes:  p' ,  q'  s.t.  p  =  2 p'  +  1,  q  =  2 q'  +  1  are  also 
prime. 

2.  n  <—  pq,  e  ZJ(n),d  <-  e_1  mod  0(n) 

3.  For  each  user  (Alice): 

(a)  s  *-  k-\K,g()\-l 

(b)  €  Alice  <-  0s||/C^(TZ>j4)||1 

(c)  d Alice  <—  1/e^Hce  mod  0(n) 

(d)  d  Alice, u  *  {0} 

_ (c)  dAlice  ,sem  <—  jd  -  dAUce,u )  mod  <ft(n) _ 


Fig.  1.  IB-mRSA:  User  Key  Generation 


A  domain-  or  system-wide  certificate  ( Certorg )  is  issued  by  the  CA  after  comple¬ 
tion  of  the  key  generation  algorithm.  This  certificate  contains  almost  all  the  usual  fields 
normally  found  in  RSA  public  key  certificates  with  few  exceptions,  such  as  no  real 
public  key  value  is  given.  In  particular,  it  mainly  contains  the  common  modulus  n  and 
(if  applicable)  the  common  part  of  the  email  address  for  all  users,  such  as  the  domain 
name. 

For  the  sake  of  compatibility  with  other  (not  identity-based)  RSA  implementations 
-  including  plain  RSA  and  mRSA  -  the  CA  may,  upon  request,  issue  an  individual 
certificate  to  a  user.  In  most  cases,  however,  an  individual  user  certificate  would  not 
be  needed,  since  not  having  such  certificates  is  exactly  the  purpose  of  identity-based 
cryptography. 


2.2  IB-mRSA  Encryption 

To  encrypt  a  message,  the  sender  needs  only  the  recipient’s  email  address  and  the  do¬ 
main  certificate.  The  encryption  algorithm  is  shown  in  Figure  2. 


Algorithm  IB-mRSA. encr 

1 .  Retrieve  n,  k  and  ICG  algorithm  identifier  from  the  domain  certificate; 

2.  s  <-  k-\tcg{)\  -  i 

3.  e  <-  0a\\K,g{IDA)\\l 

4.  Encrypt  input  message  m  with  (e,  n)  using  standard  RSA/OAEP,  as  specified 
in  PKCS#lv2.1[3] 


Fig.  2.  IB-mRSA:  Encryption 
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Since  the  receiver’s  public  key  is  derived  from  the  receiver’s  unique  identifier,  the 
sender  does  not  need  a  public  key  certificate  to  ensure  that  the  intended  receiver  is  the 
correct  public  key  holder.  Furthermore,  fast  revocation  provided  by  mRSA  obviates 
the  need  for  the  sender  to  perform  any  revocation  checks.  The  decryption  process  is 
essentially  the  same  as  in  mRSA.  If  a  certain  user  needs  to  be  revoked,  the  domain 
security  administrator  merely  notifies  the  appropriate  SEM  and  the  revoked  user  is 
unable  to  decrypt  any  further  messages. 

2.3  IB-mRSA  Decryption 

IB-mRSA  decryption  is  identical  to  that  of  mRSA.  To  make  this  paper  self-contained, 
we  borrow  (from  [9])  the  protocol  description  in  Figure  3.  For  a  detailed  description 
and  security  analysis  of  additive  mRSA,  we  refer  the  reader  to  [9], 2 


Protocol  IB-mRSA. deer  (executed  by  User  and  SEM) 

1.  USER:  m!  <—  encrypted  message 

2.  USER:  send  m'  to  SEM 

3.  In  parallel: 

3.1  SEM: 

(a)  If  USER  revoked  return  (ERROR) 

(b)  P DSem  <—  m!dsern  mod  n 

(c)  Send  PDsern  to  USER 

3.2  USER: 

(a)  PDU  <—  m'du  mod  n 

4.  USER:  M  <—  ( PDsem  *  PDU)  mod  n 

5.  USER:  m  <—  OAEP  Decoding  ofM 

6.  USER:  If  succeed,  return  (m) 


Fig.  3.  IB-mRSA:  Decryption 


3  Security  of  Identity-based  mRSA 

We  now  examine  the  security  of  IB-mRSA/OAEP  in  a  setting  with  n  users.  All  users 
share  a  common  RSA  modulus  N  and  each  user  ( Ui )  is  associated  with  a  unique  identity 
IDi,  which  is  mapped  into  an  RSA  public  exponent  e,  via  a  mapping  function  ICQ. 

3.1  Security  Analysis 

In  the  following,  we  argue  that  if  ICQ  is  an  appropriate  hash  function,  IB-mRSA/OAEP 
is  semantically  secure  against  adaptive  chosen  ciphertext  attacks  (CCA-2)  in  the  ran¬ 
dom  oracle  model.  We  use  the  term  indistinguishability  which  is  a  notion  equivalent  to 
semantic  security.  (See  [6]  for  the  relevant  discussion.) 

2  There  is  also  a  very  similar  multiplicative  mRSA  (*mRSA)  first  proposed  by  Ganesan  [13]. 
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Our  analysis  is  mainly  derived  from  the  results  in  [5],  ([4]  has  similar  results)  where 
it  was  shown  that  a  public-key  encryption  system  in  a  multi-user  setting  is  semantically 
secure  against  certain  types  of  attacks  if  and  only  if  the  same  system  in  a  single-user 
setting  is  semantically  secure  against  the  same  attack  types. 

IB-mRSA/OAEP  is  obviously  an  encryption  setting  with  many  users,  although  they 
do  not  physically  possess  their  own  private  keys.  To  prove  semantic  security,  we  begin 
by  asserting  that  IB-mRS  A  in  single-user  mode  is  equivalent  to  the  standard  RS  A/OAER 
which  is  proven  secure  against  CCA-2  under  the  random  oracle  [12].  Next,  we  apply  the 
theorems  in  [5]  with  the  condition  that  all  users  are  honest.  To  remove  this  condition, 
we  analyze  the  distribution  of  views  of  the  system  from  users  and  outside  adversaries. 
Furthermore  we  introduce  an  additional  requirement  for  the  key  generation  function 
(division-intractability)  so  that  we  can  neglect  the  possibility  of  an  attack  from  legiti¬ 
mate  (inside)  users,  which  is  a  problem  unique  to  our  setting.  In  the  end,  we  argue  for 
semantic  security  of  IB-mRSA/OAEP. 

We  use  Succ[B(t,  qf)  to  denote  the  maximum  advantage  of  all  adversary  algorithms 
in  polynomial  time  t,  attacking  IB-mRSA/OAEP  with  one  user,  SuccrnB (t.  qrj .  qe)  for 
the  setting  with  n  users,  and  SuccR(t ,  q,i)  for  RSA/OAEP.  In  the  above,  qd(qe )  denote 
the  maximum  number  of  decryption  (encryption)  queries  allowed  for  each  public  key. 
Throughout  the  analysis,  we  consider  semantic  security  against  CCA-2  under  the  ran¬ 
dom  oracle  assumption.  To  conserve  space,  we  omit  mentioning  them  in  the  following 
discussion. 

We  begin  with  the  following  lemma. 

Lemma  1.  IB-mRSA/OAEP  system  in  a  single-user  setting  is  polynomially  as  secure 
as  standard  RSA/OAEP  encryption,  i.  e. , 

Succ[B(t,qd)  =  SuccR(t',qd ) 
where  c  is  constant  value,  t'  =  t  +  c. 

The  proof  is  in  Appendix  A.2.  Basically,  if  there  exists  an  algorithm  breaking  the  se¬ 
curity  of  IB-mRSA/OAEP  in  a  single-user  mode,  we  can  build  upon  it  an  algorithm 
breaking  standard  RSA/OAEP  with  the  same  success  probability  and  constant  extra 
overhead.  Of  course,  it  is  easy  to  see  that  breaking  RSA/OAEP  implies  breaking  IB- 
mRSA.  Thus,  we  claim  that  they  are  equally  secure. 

For  the  multi-user  setting,  we  cannot  claim  that  IB-mRSA  with  n  users  is  seman¬ 
tically  secure  by  directly  applying  the  security  reduction  theorem  in  [5].  The  reason  is 
that  our  system  is  not  a  typical  case  referred  in  [5],  Sharing  a  common  RSA  modulus 
among  many  users  results  in  their  respective  trapdoors  not  being  independent;  conse¬ 
quently,  there  could  be  attacks  among  the  users.  Furthermore,  users  in  IB-mRSA  may 
have  the  incentive  not  only  to  attack  other  users,  but  also  to  attempt  to  break  the  under¬ 
lying  protocol  so  that  they  can  bypass  the  mandatory  security  control  of  the  SEM. 

However,  assuming  for  the  moment,  that  all  users  are  honest,  we  can  obtain  the 
following  lemma  derived  from  [5], 

Lemma  2.  IB-mRSA/OAEP  system  with  n  users  is  semantically  secure  if  all  n  are  hon¬ 
est.  More  precisely, 
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S ucc^8 (tn,qd,qe)  <  qenSucc[B (ti,  qd) 
where  ti  =  tn  +  0(log(qen)) 

When  all  users  are  honest,  there  are  clearly  no  attacks.  Thus,  IB-mRSA  with  multi-user 
can  be  considered  as  an  example  of  encryption  system  in  [5]  where  each  user  has  an  in¬ 
dependent  trapdoor.  We  adapt  the  original  proof  in  [5]  in  order  to  claim  security  against 
CCA-2  since  no  user  actually  knows  its  own  trapdoor  in  IB-mRSA.  See  Appendix  A. 3 
for  details. 

Unfortunately,  in  a  real  application,  all  users  cannot  be  assumed  to  be  trusted.  To 
remove  this  condition  in  Lemma  2,  we  have  to  examine  both  the  information  an  inside 
user  can  observe  and  the  operations  an  inside  user  can  perform. 

For  a  given  entity  (user  or  set  of  users)  we  use  an  informal  term  “system  view”  to 
refer  to  the  distribution  of  all  inputs,  outputs,  local  state  information  as  well  as  scripts 
of  interactions  with  decryption  oracles,  encryption  oracles,  and  the  SEM.  The  system 
view  for  an  outside  attacker  is  denoted  as: 

Vi  ::=  Pr{N,  (eo, . . .  en),  ro,rE,  Pd^sem} 

while  the  system  view  for  a  set  of  users  is: 

V2  ::=  Pr{N,  ( eo , .  •  • ,  en),  {dUi},  To,  PE,  Pd,Psem,  Pdu,n} 

where  {dUi}  is  the  set  of  user  key-shares;  / o ■  PE.  I  );>  are  three  scripts  recording  all 
queries/answers  to  the  random  oracle,  encryption  oracles  and  decryption  oracles,  re¬ 
spectively;  rsEM  is  the  script  recording  all  requests/replies  between  all  users  and  the 
SEM;  r,iu,ri  is  the  script  recording  all  n  users’  computation  on  ciphertexts  with  their 
own  secret  key-share  dUi .  We  claim  in  Lemma  3,  that  being  an  IB-mRSA  user  does  not 
afford  one  extra  useful  information  as  compared  to  an  outside  adversary. 

Lemma  3.  Under  the  adaptive  chosen  ciphertext  attack,  the  system  view  of  the  outside 
adversary  (V\),  is  polynomially  indistinguishable  from  the  combined  system  view  (V2) 
of  a  set  of  malicious  insiders,  in  the  random  oracle  model. 

Proof  See  Appendix  A. 4  for  details.  □ 

Thus  far,  we  have  shown  that  insider  adversaries  do  not  gain  advantages  over  out¬ 
siders  in  terms  of  obtaining  extra  information.  However,  we  also  need  to  consider  the 
privileged  operations  that  an  insider  can  make.  In  IB-mRSA,  each  user  is  allowed  to 
send  legitimate  decryption  queries  to  its  SEM.  In  conventional  proofs,  the  adversary  is 
not  allowed  to  query  its  oracle  for  the  challenge  ciphertext.  However  in  our  case,  an  in¬ 
side  adversary  can  manipulate  a  challenge  ciphertext  (intended  for  decryption  with  df) 
into  another  ciphertext  that  can  be  decrypted  with  its  own  key  dj  and  legally  decrypt  it 
with  the  aid  of  the  SEM.3 

3  A  simple  example  is  as  follows.  Suppose  a  =  3  *  ej.  Then,  given  c  =  mej  mod  n.  User  Ui 
can  compute  d  =  c3  =  me*  mod  n,  which  can  be  decrypted  by  17,  with  the  help  from  its 
SEM.  The  notion  of  non-malleability  does  not  capture  this  attack  since  it  is  defined  under  a 
single  fixed  private/public  key  pair. 
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We  now  have  to  consider  the  probability  of  such  attacks  in  our  setting.  More  gener¬ 
ally,  let  eao, . . . ,  eav  be  the  set  of  public  keys  of  v  malicious  users,  and  Ev  =  eai. 
They  may  attempt  to  use  some  function  /,  which  takes  a  challenge  c  =  mx  mod  n  as 
input  and  outputs  ciphertext  d  =  mEv .  We  offer  the  following  lemma  to  address  the 
conditions  for  the  existence  of  such  /. 

Lemma  4.  Given  two  RSA  exponents  x,  y  and  modulus  n,  let  f  be  a  polynomial  time 
complexity  function  s.t.  f(mx)  =  mv  mod  n.  Such  f  exists  iff  x\y. 

Proof  See  Appendix  A. 5  for  details.  □ 

According  to  Lemma  4,  we  require  negligible  probability  of  obtaining  a  user’s  pub¬ 
lic  key  which  is  a  factor  of  the  product  of  a  set  of  others.  A  similar  requirement  ap¬ 
pears  in  a  signature  scheme  by  Gennaro  et  al.  in  [14].  They  introduce  the  notion  of 
division  intractability  for  a  hash  function.  Informally,  a  hash  function  H  is  Division 
intractable  if  it  is  infeasible  to  find  distinct  (Xi, . . . ,  Xn .  Y)  in  its  domain,  such  that 
H{Y)  \  J~[-(fT(Xj)).  Denoting  Prdlv(H)  as  the  probability  that  H  fails  to  hold  this 
property,  we  have  the  following  proposition  regarding  the  security  of  IB-mRSA  in  a 
multi-user  setting. 

Proposition  1.  IB-mRSA/OAEP  encryption  offers  equivalent  semantic  security  to 
RSA/OAEP  against  adaptive  chosen  ciphertext  attacks  in  the  random  oracle  model,  if 
the  key  generation  function  is  division  intractable. 

In  summary.  Lemma  3  and  Lemma  4  enable  us  to  remove  the  condition  of  Lemma  2 
where  all  users  are  assumed  to  be  honest,  by  requiring  the  key  generation  function  to 
be  division  intractable.  Thus,  we  can  reduce  the  security  of  IB-mRSA/OAEP  in  multi¬ 
user  setting  into  single-user,  which  is  as  secure  as  standard  RSA/OAEP  according  to 
Lemma  1. 

3.2  The  Public  Key  Mapping  Function 

The  key  generation  function  K.Q  in  IB-mRSA  is  a  hash  function  //.  To  ensure  the  secu¬ 
rity  of  the  scheme,  H  must  satisfy  the  following  requirements. 

Availability  of  Public  Keys:  The  output  of  H  should  have  an  overwhelming 
probability  of  being  relatively  prime  to  <j>(ri).  Obviously,  for  the  inverse  (private  key)  to 
exist,  a  public  exponent  can  not  have  common  factors  with  (f>(n). 

Note  that  in  Section  2  the  RSA  modulus  n  is  set  to  n  =  p  *  q  and  p,  q  are  chosen 
as  strong  primes  p  =  2 p'  +  1,  q  =  2 q'  +  1  where  both  p'  and  q'  are  also  large  primes. 
Considering  <j)(n )  =  22p'q'  with  only  three  factors  2,  p ,  q ,  the  probability  of  the  output 
from  H  being  co-prime  to  <j>(n)  is  overwhelming  on  the  condition  that  the  output  is  an 
odd  number,  because  finding  an  odder  number  not  co-prime  to  4 p'q'  is  equivalent  to 
find  p'  or  q'  and  consequently  factoring  n. 

Collision  Resistance:  H  should  be  a  collision-resistant  function,  i.e.,  given 
any  two  distinct  inputs  ID\,IDi,  the  probability  of  H ( / 1)\ )  =  II ( 1 1)> )  should  be 
negligible.  In  other  words,  no  two  users  in  the  domain  can  share  the  same  public  expo¬ 
nent. 


47 


DIVISION  Resistance:  As  discussed  in  Section  3.1,  division  intractability  of 
H  is  essential  to  the  security  of  IB-mRSA.  Gennaro  et  al.  analyzed  the  probability  of 
division  for  hash  functions  in  [14]. 

Moreover,  Coron  and  Naccache  showed  in  [11]  that  the  number  of  necessary  hash- 
value  to  find  a  division  relation  among  a  hash  function’s  outputs  is  sub-exponential  to 
its  digest  size  k:  exp{^/ 2  log  2/2  +  o(l)y/k  log  k). 

They  suggested  using  1024-bit  hash  functions  to  get  a  security  level  equivalent  to 
1024-bits  RSA.  However,  such  a  strong  hash  function  is  not  needed  in  our  case.  As 
a  point  of  comparison,  the  GHR  signature  scheme  [14]  needs  a  division-intractable 
hash  function  to  compute  message  digests,  where  an  adaptive  adversary  can  select  any 
number  of  inputs  to  the  underlying  hash  function.  IB-mRSA  needs  a  hash  function  to 
compute  digests  from  users’  identities.  In  any  domain,  the  number  of  allowed  identities 
is  certainly  much  fewer  compared  to  the  number  of  messages  in  [14]. 


digest  size  in  bits 

log2  complexity  (in  #  of  operations) 

128 

36 

160 

39 

192 

42 

1024 

86 

Table  1.  Estimated  complexity  of  the  attack  for  variable  digest  sizes. 


To  help  select  the  best  hash  size  for  our  purposes,  we  quote  from  the  experiments 
by  Coron  and  Naccache  [11]  in  Table  1.  Taking  the  first  line  as  an  example,  an  inter¬ 
pretation  of  the  data  is  that,  among  at  least  236  hash  digests,  the  probability  of  finding 
one  hash  value  dividing  another  is  non-negligible.  In  IB-mRSA  setting,  the  typical  per¬ 
sonnel  of  an  organization  is  on  the  order  of  210  ~  217.  Consequently,  the  possible 
number  of  operations  is  far  less  than  236.  Hence,  we  can  safely  use  MD5  or  SHA-1  as 
the  mapping  function  (H). 

3.3  SEM  Security 

Suppose  that  the  attacker  is  able  to  compromise  the  SEM  and  expose  the  secret  key 
dsem ,  however,  without  collusion  with  any  user.  This  only  enables  the  attacker  to  “un¬ 
revoke”  previously  revoked,  or  block  possible  future  revocation  of  currently  valid,  cer¬ 
tificates.  The  knowledge  of  dsern  does  not  enable  the  attacker  to  decrypt  or  sign  mes¬ 
sages  on  behalf  of  the  users.  The  reason  is  obvious:  note  that  Alice  never  sends  her 
partial  results  to  her  SEM.  Thus,  the  attacker’s  view  of  Alice  can  be  simulated  in  the 
normal  RSA  setting,  where  the  attacker  just  picks  a  random  number  as  dsem  and  make 
computations  on  the  ciphertext,  messages  to  sign  and  signatures  generated  by  Alice. 

3.4  Security  of  Common  Modulus 

As  mentioned  earlier,  using  a  common  RSA  modulus  is  clearly  unacceptable  in  plain 
RSA  setting.  In  the  mediated  RSA  architecture,  sharing  a  modulus  is  feasible  since  no 
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party  knows  a  complete  private/public  key-pair.  In  fact,  no  coalition  of  users  is  able  to 
compute  a  public/private  key-pair.  The  only  way  to  “break”  the  system  appears  to  be  by 
subverting  a  SEM  and  colluding  with  a  user.  Thus,  in  the  context  of  IB-mRSA  we  need 
to  assume  that  a  SEM  is  a  fully  trusted  party,  as  opposed  to  semi-trusted  in  mRSA  [9]. 


4  Performance  Analysis 

When  plain  RSA  is  used  for  encryption,  the  public  encryption  exponent  e  is  typically 
a  small  integer  with  only  a  few  1-bits.  One  example  is  the  popular  OpenSSL  toolkit 
[17]  which  uses  65,  537  as  the  default  public  key  value  for  RSA  certificates.  Encryption 
with  such  small  exponents  can  be  accelerated  with  specialized  algorithms  for  modular 
exponentiation.  However,  in  IB-mRSA  setting,  there  is  no  such  luxury  of  choosing  spe¬ 
cial  exponents  and  a  typical  public  exponent  is  a  relatively  large  integer  with  (on  the 
average)  half  of  the  bits  set  to  1 . 


Keys 

RSA  Modulus  1Kb 

RSA  Modulus  2Kb 

RSA  Modulus  4Kb 

65,537 

2  ms 

4  ms 

12  ms 

128-bit  key 

7  ms 

20  ms 

69  ms 

160-bit  key 

8  ms 

25  ms 

88  ms 

Table  2.  IB-mRSA  Encryption:  Performance  Comparison  of  Different  Encryption  Keys. 


We  ran  some  simple  tests  to  assess  the  cost  of  IB-mRSA  encryption  for  public 
keys  derived  from  email  addresses.  The  encryption  was  tested  using  OpenSSL  on  an 
800MHz  PHI  workstation.  In  the  tests,  we  used:  1)  “default”  encryption  exponent  65,  537 
and  2)  two  other  exponents  of  length  128-bit  and  160-bit.  For  each  key,  we  randomly 
set  half  of  the  bits.  The  results  are  depicted  in  Table  2. 

From  the  results  in  Table  2,  we  see  that  encryption  with  a  randomized  key  does 
introduce  overhead,  especially  when  the  RSA  modulus  size  grows.  However,  it  is  rather 
negligible  for  the  1024-bit  case,  which  is  currently  the  most  popular  modulus  size. 

The  decryption  cost  for  IB-mRSA  is  identical  to  mRSA.  The  performance  of  mRSA 
has  been  reported  on  by  Boneh,  et  al.  in  [9].  For  example,  a  1024-bit  mRSA  decryption 
costs  around  35ms  on  an  800  MHz  PHI,  as  compared  to  7.5ms  for  plain  RSA  on  the 
same  platform.  We  note  that  this  is  still  much  cheaper  than  40ms  that  is  needed  for 
Boneh/Franklin  IBE  decryption  (for  1024  bits  of  security  on  a  even  more  powerful 
hardware  platform). 


5  IB-mRSA  versus  Boneh/Franklin  IBE 

We  now  provide  a  detailed  comparison  of  BF-IBE  and  IB-mRSA.  The  comparison  is 
done  along  several  aspects,  including:  practicality,  revocation,  security  and  cost  of  key 
generation. 
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Practicality  and  Performance:  Although  BF-IBE  and  IB-mRSA  have  similar  architec¬ 
tures,  the  underlying  cryptographic  primitives  are  completely  different.  Compared  to 
the  elliptic  curve  primitives  used  in  BF-IBE,  IB-mRSA  is  much  easier  to  deploy  since 
RSA  is  currently  the  most  popular  public  key  encryption  method.  Recall  that  IB-mRSA 
is  fully  compatible  with  standard  RSA  encryption.  Moreover,  if  optional  individual  cer¬ 
tificates  are  used,  IB-mRSA  is  fully  compatible  with  current  PKI-s.  Thus,  it  offers  a 
smooth  and  natural  transition  from  normal  ID-based  to  public  key  cryptography. 

In  addition,  IB-mRSA  offers  better  performance  than  BF-IBE.  As  seen  from  the 
comparison  in  Table  3,  IB-mRSA  is  noticeably  faster  than  BF-IBE  in  both  key  genera¬ 
tion  and  message  encryption. 


BF-IBE 

IB-mRSA 

Private  Key  Generation 

3  ms 

<  1ms 

Encryption  Time 

40ms 

7ms 

Decryption  Time 

40ms 

35ms 

Table  3.  Performance  Comparison  of  BF-IBE  (on  PHI  1GHz)  and  IB-mRSA  (on  PHI  800MHz) 
with  1024-bit  security. 


Revocation:  BF-IBE  does  not  explicitly  provide  revocation  of  users’  security  capabili¬ 
ties.  This  is  natural  since  it  aims  to  avoid  the  use  of  certificates  in  the  course  of  public 
key  encryption.  On  the  other  hand,  revocation  is  often  necessary  and  even  imperative. 

The  only  way  to  obtain  revocation  in  normal  IBE  is  to  require  fine-grained  time- 
dependent  public  keys,  e.g.,  public  keys  derived  from  identifiers  combined  with  time-  or 
date-stamps.  This  has  an  unfortunate  consequence  of  having  to  periodically  re-issue  all 
private  keys  in  the  system.  Moreover,  these  keys  must  be  (again,  periodically)  securely 
distributed  to  individual  users.  In  contrast,  IB-mRSA  inherits  its  fine-grained  revocation 
functionality  from  mRSA  [9].  IB-mRSA  provides  per-operation  revocation,  whereas, 
BF-IBE  provides  periodic  revocation,  which  clearly  has  coarser  granularity.  Essentially, 
IB-mRSA  allows  revocation  to  commence  at  any  time  while  BF-IBE  revokes  users  by 
refusing  to  issue  new  private  keys.  However,  BF-IBE  does  not  prevent  the  type  of  an 
attack  whereby  an  adversary  who  compromises  a  previous  or  current  key  can  use  them 
to  decrypt  previously  encrypted  messages.  This  can  be  a  serious  attack  in  some  settings, 
such  as  military  applications. 

Trusted  Third  Parties:  Both  SEM  in  IB-mRSA  and  PKG  in  BF-IBE  are  trusted  third 
parties.  However,  the  difference  in  the  degree  of  trust  is  subtle.  A  SEM  is  fully  trusted 
since  its  collusion  with  any  user  can  result  in  a  compromise  of  all  other  users’  secret 
keys,  due  to  the  shared  RSA  modulus.  Nonetheless,  a  compromise  of  a  SEM  alone 
does  not  result  in  a  compromise  of  any  users’  secret  keys.  A  PKG  is  a  real  TTP  since  it 
knows  all  users’  secrets,  thus,  a  compromise  of  a  PKG  results  in  a  total  system  break. 
While  a  PKG  can  also  be  a  CA  at  the  same  time,  a  SEM  can  never  be  allowed  to  play 
the  role  of  CA. 


50 


If  BF-IBE  is  used  to  provide  fine-grained  revocation,  frequent  key  generation  and 
secure  key  distribution  are  expensive  procedures.  Although  a  PKG  is  not  required  to  be 
on-line  all  of  the  time,  in  practice,  it  must  be  constantly  available  since  users  do  not  all 
request  their  current  private  keys  at  the  same  time.  Therefore,  as  the  revocation  interval 
in  BF-IBE  gets  smaller,  the  on-line  presence  of  a  PKG  becomes  more  necessary. 


6  Implementation 

We  implemented  IB-mRS  A  for  the  purposes  of  experimentation  and  validation.  The  im¬ 
plementation  is  publicly  available  at  http://sconce.ics.uci.edu/sucses. 
The  software  is  composed  of  three  parts: 

1.  CA  and  Admin  Utilities:  domain  certificate,  user  key  generation,  (optional)  certifi¬ 
cate  issuance  and  revocation  interface. 

2.  SEM  daemon:  SEM  process  as  described  in  Section  2 

3.  Client  libraries:  IB-mRSA  user  functions  accessible  via  an  API. 

The  code  is  built  on  top  of  the  popular  OpenSSL  [17]  library.  OpenSSL  incorpo¬ 
rates  a  multitude  of  cryptographic  functions  and  large-number  arithmetic  primitives.  In 
addition  to  being  efficient  and  available  on  many  common  hardware  and  software  plat¬ 
forms,  OpenSSL  adheres  to  the  common  PKCS  standards  and  is  in  the  public  domain. 
The  SEM  daemon  and  the  CA/ Admin  utilities  are  implemented  on  Linux,  while  the 
client  libraries  are  available  on  both  Linux  and  Windows  platforms. 

In  the  initialization  phase,  a  CA  initializes  the  domain-wide  cryptographic  setting, 
namely  (ri,  p.  q,  j/ ,  q' )  and  selects  a  mapping  function  (currently  defaulting  to  MD5) 
for  all  domain  clients.  The  set  up  process  follows  the  description  in  Section  2.  For  each 
user,  two  structures  are  exported:  1)  SEM  bundle ,  which  includes  the  SEM’s  half-key 
dfEM ,  and  2)  user  bundle,  which  includes  <i“  and  the  entire  server  bundle. 

The  server  bundle  is  in  PKCS#7[1]  format,  which  is  basically  a  RSA  envelope 
signed  by  the  CA  and  encrypted  with  the  SEM’s  public  key.  The  client  bundle  is  in 
PKCS#12[2]  format,  which  is  a  shared-key  envelope  also  signed  by  the  CA  and  en¬ 
crypted  with  the  user-supplied  key  which  can  be  a  pre-set  key,  a  password  or  a  pass- 
phrase.  (A  user  is  not  assumed  to  have  a  pre-existing  public  key.) 

After  issuance,  each  user  bundle  is  distributed  in  an  out-of-band  fashion  to  the  ap¬ 
propriate  user.  Before  attempting  any  IB-mRSA  transactions,  the  user  must  first  decrypt 
and  verify  the  bundle.  A  separate  utility  program  is  provided  for  this  purpose.  With  it, 
the  bundle  is  decrypted  with  the  user-supplied  key,  the  CA’s  signature  is  verified,  and, 
finally,  the  user’s  half-key  are  extracted  and  stored  locally. 

To  decrypt  a  message,  the  user  starts  with  sending  an  IB-mRSA  request,  with  the 
SEM  bundle  piggybacked.  The  SEM  first  check  the  status  of  the  client.  Only  when  the 
client  is  deemed  to  be  a  legitimate  user,  does  the  SEM  process  the  request  using  the 
bundle  contained  therein.  As  mentioned  earlier,  in  order  to  encrypt  a  message  for  an 
IB-mRSA,  that  user’s  domain  certificate  needs  to  be  obtained.  Distribution  and  man¬ 
agement  of  domain  certificates  is  assumed  to  be  done  in  a  manner  similar  to  that  of 
normal  certificate,  e.g.,  via  LDAP  or  DNS. 
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6.1  Emailer  client  plug-in 


To  demonstrate  the  ease  of  using  IB-mRSA  we  implemented  plug-ins  for  the  popular 
Eudora[19]  and  Outlook[16]  mailers.  The  plug-ins  allow  the  sender  to  encrypt  outgoing 
emails  to  any  client  in  the  common  domain  using  only  one  domain  (organizational) 
certificate.  When  ready  to  send,  the  sender’s  plug-in  reads  the  recipient’s  email  address 
and  looks  up  the  organization  certificate  by  using  the  domain  name  in  the  email  address. 
A  screen  snapshot  of  the  Eudora  plug-in  is  shown  in  Figure  4. 


Fig.  4.  Eudora  IBE  Plugin 


When  an  email  message  encrypted  with  IB-mRSA  is  received,  an  icon  for  IB-mRSA 
is  displayed  in  the  message  window.  To  decrypt  the  message,  the  user  just  clicks  on  the 
IB-mRSA  icon.  The  plug-in  then  contacts  the  user’s  SEM  to  get  a  partially  decrypted 
message  (if  the  user  is  not  revoked).  This  is  basically  the  same  process  as  in  mRSA. 


7  Summary  and  Future  Work 

We  described  IB-mRSA,  a  practical  and  secure  identity-based  encryption  scheme.  It  is 
compatible  with  standard  RSA  encryption  and  offers  fine-grained  control  (revocation) 
of  users  security  privileges. 

Several  issues  remain  for  future  work.  It  is  unclear  whether  IB-mRSA  can  be  shown 
secure  under  the  standard  model  (our  argument  utilizes  the  random  oracle  setting). 
Moreover,  we  need  a  more  formal  analysis  of  semantic  security.  Another  issue  relates  to 
IB-mRSA  performance.  Using  a  hash  function  for  public  key  mapping  makes  encryp¬ 
tion  more  expensive  than  RSA  since  the  public  exponent  is  random  (and  on  the  average 
half  of  the  bits  are  set).  We  need  to  investigate  alternative  mapping  functions  that  can 
produce  more  “efficient”  RSA  exponents. 
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A  Proof  of  Security 

A.l  Notations  and  Attack  Model 

Throughout  the  appendix,  we  use  the  following  notations 

-  ICQ :  Key  Generation  Function 

-  V£{):  IB-mRSA/OAEP  encryption  system. 

-  'DO,/, :  Decryption  oracle  with  private  key  d, 

-  TUCkRandom  oracle 

-  N:  The  common  RSA  modulus 

-  ei/dp.  the  i-th  user’s  public  key/private  key 

-  n :  The  number  of  users  in  V£ 

-  t/,  :The  number  of  encryptions  allowed  to  be  performed  by  each  user 

-  qd :  The  maximum  number  of  decryption  queries  the  adversary  can  ask 

Under  the  notion  of  indistinguishability  of  security,  the  adversary  A  takes  the  public  key 
and  outputs  two  equal  length  messages  m o,  m\ .  Then,  it  gets  a  challenge  ciphertext  C, 
computed  by  an  encryption  oracle  which  secretly  picks  b  Cu  {0, 1}  and  encrypts  nib- 
A  is  challenged  to  output  b  with  a  probability  non-negligibly  greater  than  1/2.  In  CCA 
attack  model,  A  is  allowed  to  send  queries  to  a  decryption  oracle,  with  the  restriction 
that  A  is  not  allowed  to  query  on  the  challenge  ciphertext  c. 

A.2  Proof  of  Lemma  1 

Proof.  The  lemma  means  that  if  there  exists  an  attack  algorithm  B  with  polynomial 
time  complexity,  breaking  the  security  of  IB-RSA/OAEP  with  success  probability  e, 
then  there  exists  an  attack  algorithm  T  with  the  same  polynomial  degree  of  running 
time,  breaking  RSA/OAEP  with  the  same  success  probability;  and  vice  versa. 

The  reverse  direction  is  obvious.  For  any  T  that  can  break  the  indistinguishability  of 
standard  RSA,  it  breaks  IB-mRSA  in  single-user  mode.  Thus  we  have  SuccR(t' ,  qf)  < 
Succ(B(t ,  qd).  Now  we  show  Succ[B(t,  qd)  <  SuccR(t',  qd). 

Let  B  be  the  polynomial  algorithm  attacking  on  the  indistinguishability  of  V£ (ICQ,  N,  1) 
containing  the  single  user  Uq  and  its  public  key  eo  and  secret  bundle  dUo.  By  allowing 
B  to  know  dUQ,  we  model  the  concern  that  the  user  in  the  system  may  be  malicious. 

We  construct  T  as  the  adversary  algorithm  against  the  standard  RSA/OAEP  (N,  e)  and 
analyze  its  success  probability  and  time  complexity.  Replacing  ICQ  function  in  V£  by 
a  random  oracle  and  acting  as  the  random  oracle  and  decryption  oracle  for  B,  A  runs  T 
as  follows. 
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Experiment  VRSA(N,  e,  VOd ,  HO) 

Select  two  random  messages  (mo,  mi)  with  equal  length.  The  encryption  oracle 
EOe  secretly  selects  a  random  bit  b  {0,1}  and  encrypts  mb  into  the  ciphertext 
c.  Given  c,  T  runs  the  following  to  determine  b. 

1.  Generate  a  random  number  r  and  a  string  id', 

2.  Initialize  V£(K,Q,  N)  with  single-user  setting  by  N  <—  N,  For  user  I  Do  <— 
id\ 

3.  V£  queries  its  random  oracle  (J~  )  for  eo; 

4.  eo  <—  e; 

5.  Initialize  B  with  (mo,  mi,  c)  and  the  target  system  V£(K,Q,  N)  and  user  pub¬ 
lic  key  eo,  user  bundle  r; 

6.  Run  B.  The  number  of  decryption  queries  is  bounded  by  qd'- 

(a)  For  all  B’s  random  oracle  queries  on  OAEP  encoding/decoding,  T  for¬ 
wards  them  to  1ZO  and  hands  the  answers  back; 

(b)  For  all  B’s  decryption  oracle  queries,  T  forwards  them  to  VOd,  and 
hands  the  answers  back; 

(c)  For  B’s  requests  c  to  SEM  (remember  that  the  adversary  might  be  inside 
the  system):  T  queries  VOd  on  c.  On  getting  the  reply  cd  mod  n,  T 
hands  back  cd/cr  mod  n  as  the  reply  from  SEM  to  B. 

7.  B  halts  outputting  a  bit  b'\ 

8.  Return  b'\ 

Clearly,  if  B’s  output  b'  equals  b,  T  successfully  discovers  b.  This  holds  for  all 
polynomial  algorithm  B.  Thus  we  have  Succ[B(t ,  qd )  <  SuccR(t' ,  qd )■  As  for  the  time 
complexity  of  T ,  the  steps  1  ~5  and  steps  7,8  take  constant  time,  in  that  the  cost  is 
independent  of  the  security  parameter,  and  step  6  runs  in  time  t  .  Hence,  the  overall 
time  for  T  is  t  +  c,  which  leads  us  to  the  conclusion  of  Succ[B(t ,  qd)  =  SuccR(t' ,  qd)- 
□ 


A.3  Proof  of  Lemma  2 


Proof.  If  all  users  in  V£  are  considered  trusted,  we  do  not  need  to  consider  all  attacks 
originated  from  the  inside  users.  The  V£  is  therefore  a  IB-mRSA/OAEP  in  multi-user 
setting,  whose  security  for  single-mode  is  proved  in  Lemma  1. 

To  show  the  polynomial  reduction,  the  proof  in  [5]  constructs  an  attack  algorithm  B 
for  single-setting.  B  calls  another  algorithm  A,  which  can  break  the  multi-user  setting. 
In  order  to  argue  the  security  in  CCA2  model,  B  has  to  simulate  the  decryption  oracles 
for  A.  This  is  simple  in  their  case,  where  B  can  invoke  key  generation  function  to 
obtain  all  needed  public/private  key  pairs.  Unfortunately,  this  is  not  the  case  in  IB- 
mRSA  setting,  since  the  key  generation  will  not  give  B  the  private  keys.  We  slightly 
revise  the  original  proof. 

Still,  A  targets  at  a  multi-use  setting  with  public  keys  {N,  eo,  •  •  • ,  en}.  However,  we 
construct  B,  targeting  at  {N,  e  =  IT 'f0 ( e, ) } .  The  algorithm  for  Lbs  decryption  query 
is  shown  below: 
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Decryption  oracle  simulator  (  B,  A,  N,e0,...,  e„,  e  =  n"=o  e0 
B  simulates  decryption  oracle  for  A  with  the  help  from  its  own  oracle  VOd- 
( d  is  the  corresponding  secret  key  to  ( n ,  e).) 

1.  A^  B:  (c,  a), 

2.  B  — >  VOd:  c 

3.  B  <—  VOd'-  c'  =  cd  mod  n 

4.  B  computes  b  =  — 

5.  A  <—  B:  a  =  clb  mod  n 

One  can  easily  check  that  the  answer  a  is  exactly  c1/®*.  Thus,  the  proof  for  Theorem 
4.1  in  [5]  still  holds,  which  also  proves  this  lemma. 

□ 

A.4  Proof  of  Lemma  3 

Proof.  (Sketch)  No  secret  channel  is  assumed  either  in  IB-mRSA  protocol  execution  or 
in  the  attack  model.  Thus,  the  outsider  observes  everything  that  the  insider  does,  except 
for  {dUi}  and  //iTt.  However,  an  outsider  can  simulate  I  \iu  >n  with  the  help  of  a  random 
oracle  and  the  decryption  oracles. 

Note  that  a  user’s  key-share  is  nothing  but  a  random  number  derived  from  an  ideal¬ 
ized  hash  function,  which  can  be  replaced  by  the  random  oracle  RO.  The  outsider  can 
query  RO  and  obtain  a  set  of  random  values  {r.j}  with  the  same  distribution  as  {dUi}. 
For  each  ciphertext  c  in  I \iu (encrypted  with  eUi)  the  adversary  constructs  n  by 
computing  cdu *  =  cdi  /cri,  where  cdi  is  obtained  from  the  decryption  oracle  VOdi- 
All  c,  dUi,ri  are  random  integers.  (Note  that  c  is  also  random  since  OAEP  encoding  is 
applied  before  exponentiation).  Thus,  Pr{rrju.n}  =  Pr{r'du  n},  which  leads  to  V\  and 
V2  having  the  same  distribution  □ 


A.5  Proof  of  Lemma  4 

Proof.  We  show  that  x\y  is  a  sufficient  and  necessary  condition  for  the  existence  of  /. 
Sufficiency:  if  x\y,  i.e.  3k  £  J\f ,  s.t.  y  =  kx.  We  construct  /  as 

/  :  a  — *  ak  mod  n 

One  can  easily  check  that  /  is  the  desired  function. 

Necessity:  Suppose  there  exists  a  function  /  satisfying  the  requirement,  while  y  = 
kx  +  r,  where  k,r  £  AT  and  1  <  r  <  x.  Given  c  =  mx  mod  n,  we  can  compute  c\  = 
/(c)  =  mv  mod  n.  Suppose  g  =  gcd(x ,  y),  i.e  3a,  b  £  Z,  s.t.  ax  +  by  =  g.  Thus,  in 
polynomial  time,  we  can  get  m9  by  computing  cac\  mod  n.  If  we  let  x  =  hg ,  we  have 
actually  constructed  a  polynomial-time  algorithm,  which,  taking  c  =  ( m9)h  mod  n  and 
h,  n  as  input,  outputs  c1^  mod  n  without  knowing  the  factorization  of  n.  (Note  that  x 
is  relatively  prime  to  < f>(n ),  which  implies  that  h  is  also  relatively  prime  to  <j>(ri)  and  is 
a  valid  RSA  public  key  exponent.)  However,  this  contradicts  the  RSA  assumption.  □ 
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Abstract.  Identity-based  encryption  (IBE)  [5]  and  digital  signatures  are  impor¬ 
tant  tools  in  modern  secure  communication.  In  general,  identity-based  crypto¬ 
graphic  methods  facilitate  easy  introduction  of  public  key  cryptography  by  al¬ 
lowing  an  entity’s  public  key  to  be  derived  from  some  arbitrary  identification 
value  such  as  an  email  address  or  a  phone  number.  Identity-based  cryptography 
greatly  reduces  the  need  for,  and  reliance  on,  public  key  certificates. 

Mediated  RSA  (mRSA)  [4]  is  a  simple  and  practical  method  of  splitting  RSA 
private  keys  between  the  user  and  the  Security  Mediator  (SEM).  Neither  the  user 
nor  the  SEM  can  cheat  one  another  since  each  signature  or  decryption  must  in¬ 
volve  both  parties.  mRSA  allows  fast  and  fine-grained  control  (revocation)  over 
users’  security  privileges.  However,  mRSA  still  relies  on  public  key  certificates 
to  derive  public  keys. 

Current  identity-based  cryptographic  methods  do  not  support  fine-grained  revo¬ 
cation  while  mediated  cryptography  (such  as  mRSA)  still  relies  on  public  key 
certificates  to  derive  public  keys.  In  this  paper  we  present  IB-mRSA,  a  variant 
of  mRSA  that  combines  identity-based  and  mediated  cryptography.  IB-mRSA  is 
simple,  secure  and  very  efficient. 


1  Introduction 

In  a  typical  public  key  setting,  a  user’s  public  key  is  explicitly  encoded  in  a  public  key 
certificate  which  is,  essentially,  a  binding  between  the  certificate  holder’s  identity  and 
the  claimed  public  key.  This  common  PKI  model  requires  universal  trust  in  certificate 
issuers  (Certification  Authorities  or  CAs).  This  also  has  some  well-known  side-effects 
such  as  cross-domain  trust  and  certificate  revocation.  The  main  problem,  however,  is  the 
basic  assumption  that  all  certificates  are  public,  ubiquitous  and,  hence,  readily  available 
to  anyone.  We  note  that  this  assumption  is  not  always  realistic,  especially,  in  wireless 
networks  where  connectivity  is  sporadic. 

In  contrast,  identity-based  cryptography  changes  the  nature  of  obtaining  public 
keys  by  constructing  a  one-to-one  mapping  between  identities  and  public  keys.  Thus, 
identity-based  cryptography  greatly  reduces  the  need  for,  and  reliance  on,  public  key 
certificates  and  certification  authorities.  Generally  speaking,  identity-based  encryption 
and  identity-based  digital  signatures  are  useful  cryptographic  tools  that  facilitate  easy 
introduction  of,  and/or  conversion  to,  public  key  cryptography  by  allowing  a  public  key 
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to  be  derived  from  arbitrary  identification  values  such  as  email  addresses  or  phone  num¬ 
bers.  At  the  same  time,  identity-based  methods  greatly  simplify  key  management  since 
they  reduce  both:  the  need  for,  and,  the  number  of,  public  key  certificates.  However,  one 
notable  drawback  is  that  current  identity-based  cryptographic  methods  do  not  support 
fine-grained  revocation.  (Revocation  is  typically  done  via  Certificate  Revocation  Lists 
-  CRLs  or  similar  structures.) 

Mediated  RSA  [4]  is  a  simple  and  practical  method  of  splitting  RSA  private  keys 
between  the  user  and  the  SEM.  Neither  the  user  nor  the  SEM  can  cheat  one  another 
since  each  signature  or  decryption  operation  must  involve  both  parties.  mRSA  allows 
fast  and  fine-grained  control  (revocation)  of  users’  security  privileges.  However,  mRSA 
still  relies  on  public  key  certificates  to  derive  public  keys. 

Our  goal  in  this  paper  is  to  combine  the  attractive  features  of  identity-based  cryp¬ 
tography  with  the  fine-grained  control  of  mRSA.  To  this  end,  we  present  IB-mRSA,  a 
variant  of  mRSA  that  combines  identity-based  and  mediated  cryptography.  IB-mRSA 
is  simple,  secure  and  very  efficient. 

Organization:  The  rest  of  this  paper  is  organized  as  follows.  In  the  next  section  we 
provide  a  brief  overview  of  mediated  RSA.  Next,  we  describe  IB-mRSA  in  Section  3 
and  analyze  its  security.  Sections  5  and  6  discuss  the  implementation  of  IB-mRSA  and 
its  performance,  respectively. 


2  Overview  of  Mediated  RSA 

Mediated  RSA  (mRSA)  involves  a  special  entity,  called  a  SEM  an  on-line  partially 
trusted  server.  To  sign  or  decrypt  a  message,  Alice  must  first  obtain  a  message-specific 
token  from  the  SEM.  Without  this  token  Alice  can  not  use  her  private  key.  To  revoke 
Alice’s  ability  to  sign  or  decrypt,  the  administrator  instructs  the  SEM  to  stop  issuing 
tokens  for  Alice’s  public  key.  At  that  instant,  Alice’s  signature  and/or  decryption  capa¬ 
bilities  are  revoked.  For  scalability  reasons,  a  single  SEM  serves  many  users.  One  of 
the  mRSA’s  advantages  is  its  transparency:  SEM’s  presence  is  invisible  to  other  users: 
in  signature  mode,  mRSA  yields  standard  RSA  signatures,  while  in  decryption  mode, 
mRSA  accepts  plain  RSA-encrypted  messages. 

The  main  idea  behind  mRSA  is  the  splitting  of  an  RSA  private  key  into  two  parts 
as  in  threshold  RSA  [9].  One  part  is  given  to  a  user  while  the  other  is  given  to  a  SEM. 
If  the  user  and  the  SEM  cooperate,  they  employ  their  respective  half-keys  in  a  way  that 
is  functionally  equivalent  to  (and  indistinguishable  from)  standard  RSA.  The  fact  that 
the  private  key  is  not  held  in  its  entirety  by  any  one  party  is  transparent  to  the  outside, 
i.e.,  to  the  those  who  use  the  corresponding  public  key.  Also,  knowledge  of  a  half-key 
cannot  be  used  to  derive  the  entire  private  key.  Therefore,  neither  the  user  nor  the  SEM 
can  decrypt  or  sign  a  message  without  mutual  consent. 

We  now  provide  a  brief  overview  of  mRSA  functions.  (For  a  detailed  description 
and  security  analysis  of  mRSA,  we  refer  the  reader  to  [4].)  The  variant  described  below 
is  the  additive  mRSA  (+mRSA)  as  presented  by  Boneh,  et  al.  in  [4].  (There  is  also  a 
very  similar  multiplicative  mRSA  (*mRSA)  first  proposed  by  Ganesan  [8].)  The  first 
function  +mRSA .  key  is  used  by  the  CA  to  set  up  the  user’s  public/private  key-pair  and 
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split  the  private  key  into  two  shares.  The  other  two,  +mRSA  .sign  and  +mRSA.  deer, 
are  the  signing  and  decryption  functions,  respectively.  We  note  that  no  encryption  and 
signature  verification  functions  are  specified  since  they  are  identical  to  those  in  plain 
RSA. 


lAlgorithm  +mRSA.key 

(executed  by  CA) 

Let 

k  ( 

even) 

be  the 

security  parameter 

1. 

Generate  random  fc / 2-bit  primes:  p,  q 

2. 

n  <— 

pq 

3. 

r 

e  <— 

ry * 

4. 

d 

1/e  mod  4>(n) 

5. 

yj  ,r  y 

Liu  y  ^-‘n 

-{0} 

6. 

dsern 

*-  ( d 

—  du)  mod  (j>(n) 

7. 

SK 

<—  d 

8. 

PI< 

<-  (n, 

e) 

After  computing  the  above  values,  CA  securely  communicates  dsern  to  the  SEM 
and  dv  -  to  the  user.  (See  [4]  for  details.)  The  user’s  public  key  PK  is  released,  as 
usual,  in  a  public  key  certificate. 


Protocol  +mRSA.sign  (executed  by  User  and  SEM) 

1.  USER:  h  H(m) 

where  H()  is  a  suitable  hash  function  such  as  SHA-1  and  |ff()|  <  k 

2.  USER:  send  h  to  SEM. 

3.  In  parallel: 

3.1  SEM: 

(a)  If  USER  revoked  return  (ERROR) 

(b)  P Ssem  <—  hdsem  mod  n 

(c)  send  PSaem  to  USER 

3.2  USER: 

(a)  PSU  <—  hdu  mod  n 

4.  USER:  h'  <—  ( PSsem  *  PSu)e  mod  n 

5.  USER:  If  h!  ^  h  then  return  (ERROR) 

6.  S  <—  ( PSsem  *  PSU)  mod  n 

7.  USER:  return  (h,S) 


3  Identity-Based  mRSA 

The  main  feature  of  identity-based  encryption  is  the  sender’s  ability  to  encrypt  messages 
using  the  public  key  derived  from  the  receiver’s  identity  and  other  public  information. 
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Protocol  +mRSA.decr  (executed  by  User  and  SEM) 

1.  USER:  m!  <—  encrypted  message 

2.  USER:  send  m'  to  SEM 

3.  In  parallel: 

3.1  SEM: 

(a)  If  USER  revoked  return  (ERROR) 

(b)  PDaem  <—  m'dsem  mod  n 

(c)  Send  PDsem  to  USER 

3.2  USER: 

(a)  PDU  <—  m'du  mod  n 

4.  USER:  m  <—  ( PDsern  *  PDU )  mod  n 

5.  USER:  return  (m) 


The  receiver’s  identity  can  be  the  receiver’s  email  address,  user  id  or  any  value  unique 
to  the  receiver  (essentially,  an  arbitrary  string).  To  compute  the  receiver’s  encryption 
key,  an  efficient  public  mapping  function  /()  must  be  set  beforehand.  This  function 
must  be  a  one-to-one  mapping  from  identity  strings  to  public  keys. 

The  basic  idea  behind  identity-based  mRSA  is  the  use  of  a  single  common  RSA 
modulus  n  among  all  users  of  a  system.  This  modulus  is  assumed  to  be  public  and  con¬ 
tained  in  a  public  key  certificate  issued,  as  usual,  by  some  Certificate  Authority  (CA). 
To  encrypt  a  message  for  a  certain  recipient  (Bob),  the  sender  (Alice)  first  computes 
e-Bob  =  f(IDBob)  where  IDsob  is  the  recipient’s  identity  value,  such  as  Bob’s  email 
address.  Thereafter,  the  pair  ( esob >  n)  is  treated  as  a  plain  RSA  public  key  and  normal 
RSA  encryption  is  performed.  On  Bob’s  side,  the  decryption  process  is  identical  to  that 
of  mRSA. 

We  stress  that  using  the  same  modulus  by  multiple  users  in  a  normal  RSA  setting 
is  utterly  insecure.  It  is  subject  to  a  trivial  attack  whereby  anyone  -  utilizing  one’s 
knowledge  of  a  single  key-pair  -  can  simply  factor  the  modulus  and  compute  the  other 
user’s  private  key.  However,  in  our  present  context,  we  make  an  important  assumption 
that: 


[IB-mRSA  Assumption:]  Throughout  the  lifetime  of  the  system,  the  adversary 
is  unable  to  compromise  a  SEM. 

Obviously,  without  this  assumption,  IB-mRSA  would  offer  no  security:  a  single  SEM 
break-in  coupled  with  the  compromise  of  just  one  user’s  key  share  would  result  in 
the  compromise  of  all  users’  (for  that  SEM)  private  keys.  The  IB-mRSA  assumption 
is  slightly  stronger  that  its  mRSA  counterpart.  Recall  that,  in  mRSA,  each  user  has  a 
different  RSA  setting,  i.e.,  a  unique  modulus.  Therefore,  to  compromise  a  given  user  an 
adversary  has  to  break  into  both  the  user  and  its  SEM. 

We  now  turn  to  the  detailed  description  of  the  IB-mRSA  scheme. 

3.1  System  Setting  and  User  Key  Generation 

In  the  following,  we  use  email  addresses  as  unique  identifiers  of  the  public  key  owners 
in  the  system.  However,  as  mentioned  above,  other  identity  types  can  be  used  just  as 
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well,  e.g.,  Unix  UIDs,  HTTP  addresses,  physical  addresses  or  even  phone  numbers.  We 
use  the  notation  ID  Alice  to  denote  the  user’s  (Alice)  email  address  that  will  be  used  to 
compute  the  public  exponent. 

In  the  initialization  phase,  a  trusted  party  (CA)  sets  up  the  RSA  modulus  for  all 
users  in  the  same  system  (organization  or  domain).  First,  CA  chooses,  at  random,  two 
large  primes  p'  and  q'  such  that  p  =  2 p'  +  1  and  q  =  2 q'  +  1  are  also  prime.  Then 
it  computes  n  =  pq ,  which  is,  in  fact,  a  Blum  integer.  Since  n  is  a  Blum  integer,  a 
randomly  chosen  number  in  Zn  has  negligible  probability  of  not  being  relatively  prime 
to  4>(n).  (See  Section  4  for  further  discussion.)  Hence,  our  mapping  function  /  can  be 
quite  trivial. 

The  public  exponent  is  set  to  be  the  email  address  represented  as  a  binary  string, 
padded  with  zeros  on  the  left  and  with  the  rightmost  bit  set  to  one.  This  ensures  that 
e Alice  is  odd  and,  with  overwhelming  probability,  relatively  prime  to  <j>(ri).  It  is  assumed 
that  the  email  address  is  at  most  8  bits  shorter  than  the  size  of  the  RSA  modulus.  This 
is  reasonable  considering  practical  RSA  modulus  sizes.  The  currently  recommended 
minimum  RSA  modulus  size  is  1024  bits.  Consequently,  our  assumption  translates  into 
the  email  address  being  at  most  127  characters  (bytes)  long.  We  observe  that  most  email 
addresses  tend  to  be  under  30  characters. 

In  fact,  it  is  largely  unnecessary  to  use  the  entire  email  address  as  input  to  /();  it 
suffices  to  use  only  its  leftmost  component,  i.e.,  the  “username”  portion.  This  is  because 
the  rest  of  the  address  is  common  to  all  email  users  in  the  domain.  For  example,  if  Al¬ 
ice’s  email  address  is:  Alice  .  Smith@ics  .  uci  .  edu  we  can  use  “Alice  .  Smith” 
as  input  to  /().  The  common  part  “ics  .  uci  .  edu”  can  be  assumed  to  be  part  of  the 
domain-wide  (organizational)  certificate. 

The  complete  IB-mRSA  key  generation  proceeds  as  follows: 


Algorithm  IB-mRSA. key  (executed  by  CA) 

Let  k  (even)  be  the  security  parameter 

1.  Generate  random  A: / 2-bit  primes:  p1 ,  q'  s.t.  p  =  2 p'  +  1,  q  =  2 q'  +  1  are  also 
prime. 

2.  n  <—  pq 

3.  For  each  user  (Alice): 

(a)  k!  <—  k  —  \IDAlice\  —  8 

(b)  €  Alice  <-  f  {ID  Alice)  =  0*' 1 1  TDAHce|  |00000001 

(c)  d Alice  <-  1/eAKce  mod  </>(n) 

(d)  d  Alice,  u  *  Zn  {0} 

_ (e)  d Alice, sem  *  (d  dAlice^u)  mod  0(u) _ 


A  domain-  or  system-wide  certificate  ( Certorg )  is  issued  by  the  CA  after  com¬ 
pletion  of  the  key  generation  algorithm.  This  certificate  contains  all  the  usual  fields 
normally  found  in  RSA  certificates  with  few  exceptions  discussed  later  in  Section  4.  In 
particular,  it  contains  the  common  modulus  n  and  (if  applicable)  the  common  part  of 
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the  email  address  for  all  users.  User’s  and  SEM’s  key  shares  are  distributed  securely  as 
in  the  mRSA  scheme  described  in  Section  2. 

For  the  sake  of  compatibility  with  other  (not  identity-based)  RSA  implementations 
-  including  plain  RSA  and  mRSA  -  the  CA  may,  upon  request,  issue  an  individual 
certificate  to  a  user.  In  most  cases,  however,  an  individual  user  certificate  would  not 
be  needed,  since  not  having  such  certificates  is  exactly  the  purpose  of  identity-based 
cryptography. 

3.2  IB-mRSA  Encryption 

To  encrypt  a  message,  the  sender  needs  the  recipient’s  email  address  and  its  organization 
certificate. 


Algorithm  IB-mRSA. encr 

1.  e  <—  IB  —  mRS  A.  key  (Email) 

2.  Retrieve  n  from  organization  certificate; 

3.  Let  (e,  n)  be  the  public  key  and  encrypt  message  m  using  standard  RSA  en¬ 
cryption  with  OAEP  padding. 


Note  that  the  recipient’s  public  key  certificate  is  not  required  for  the  sender  to  en¬ 
crypt.  Since  the  key  is  derived  from  the  receiver’s  unique  identifier,  the  sender  does  not 
need  a  certificate  to  ensure  that  the  intended  receiver  is  the  correct  public  key  holder. 
Furthermore,  instantaneous  revocation  provided  by  mRSA  obviates  the  need  for  the 
sender  to  perform  any  revocation  checks.  The  decryption  process  is  essentially  the  same 
as  in  mRSA:  the  security  administrator  merely  notifies  the  SEM  and  the  revoked  user 
is  unable  to  decrypt  any  further  messages. 

3.3  Signature  Protocol 

IB-mRSA  can  be  also  used  for  signing  messages.  Since  the  signing  protocol  is  the  same 
as  in  mRSA,  we  do  not  provide  a  detailed  description.  Basically,  a  user  computes  its 
own  half-signature  while  the  SEM  computes  its  half-signature.  When  the  two  parts  are 
coalesced  together,  a  full-blown  RSA  signatures  is  obtained. 

The  verification  procedure  is  slightly  different  from  mRSA  (or  plain  RSA).  In  mRSA 
and  RSA,  the  verifier  obtains  the  public  verification  key,  from  the  signer’s  public  key 
certificate.  The  certificate  can  be  obtained  from  the  signature  structure  itself  or  from 
some  public  site.  In  ID-based  signature  schemes,  the  verifier  computes  the  signer’s 
public  key  using  the  signer’s  identity.  In  IB-mRSA,  as  mentioned  before,  we  still  need 
a  domain  certificate,  which  includes  the  common  RSA  modulus  n.  However,  we  should 
point  it  out  that  this  certificate  is  not  a  normal  public  key  certificate  but  a  sort  of  an 
attribute  certificate  for  the  entire  domain.  The  verification  protocol  is  as  follows: 

Note  that,  since  signature  generation  is  the  same  as  in  mRSA,  the  binding  signature 
semantic  is  preserved  [4],  This  means  that  the  verifier  can  be  sure  that  the  signer’s 
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Algorithm  IB-mRSA. verify 

1.  Extract  and  verify  domain  certificate  from  signature  or  from  a  public  site. 

2.  Obtain  RSA  modulus  n  from  domain  certificate; 

3.  e  <—  IB  —  mRSA.key(Email)', 

4.  Let  (e,  n)  be  the  public  key  and  verify  the  signature  using  standard  RSA  ver¬ 
ification  algorithm  with  OAEP  padding. 


private  key  was  valid  (believed  by  the  SEM  to  be  valid)  at  the  time  the  signature  was 
computed. 


4  Security  Analysis 

In  this  section,  we  discuss  some  security  issues  unique  to  IB-mRS  A.  Clearly,  the  biggest 
security  concern  for  IB-mRSA  is  the  use  of  the  common  modulus  for  all  users  within 
the  same  domain. 

SEM  Security:  Let  us  consider  an  attacker  trying  to  decrypt  a  message  sent  to  Alice 
or  to  forge  Alice’s  signature  on  a  certain  message.  Recall  that  the  token  sent  by  SEM 
back  to  Alice  is  t  =  xdsem  mod  N  for  some  value  of  x.  The  attacker  sees  both  x  and 
the  token  t.  In  fact,  since  there  is  no  authentication  of  the  user’s  request  to  the  SEM,  the 
attacker  can  obtain  this  t  for  any  x  of  its  choice.  We  claim  that  this  information  is  of  no 
use  to  the  attacker.  The  reason  is  that,  dsem  is  just  a  random  number  in  Zn  independent 
of  the  rest  of  the  attacker’s  view.  Using  a  simulation  argument,  we  claim  that  any  attack 
possible  with  the  SEM  can  be  mounted  to  attack  standard  RSA.  One  can  simulate  the 
SEM  by  picking  a  random  integer  dsem  G  r  Zn  and  thus  use  the  attack  on  the  SEM  to 
mount  an  attack  on  standard  RSA. 

Suppose  the  attacker  is  able  to  compromise  the  SEM  and  expose  the  secret  key 
dsem.  This  enables  the  attacker  to  “un-revoke”  previously  revoked,  or  block  possible 
future  revocation  of  currently  valid,  certificates.  However,  knowledge  of  dsem  does  not 
enable  the  attacker  to  decrypt  or  sign  messages  on  behalf  of  its  users.  The  reason  is  ob¬ 
vious:  Note  that  Alice  does  not  send  her  partial  results  to  her  SEM.  Thus  the  attacker’s 
view  of  Alice  can  be  simulated  in  the  normal  RSA  setting,  where  the  attacker  just  picks 
a  random  number  as  dsem  and  make  computations  on  the  ciphertext,  messages  to  sign 
and  signatures  generated  by  Alice. 

Security  of  Common  Modulus:  As  mentioned  earlier,  using  a  common  RSA  modulus 
is  clearly  unacceptable  in  plain  RSA  setting.  In  the  mediated  RSA  architecture,  sharing 
a  modulus  is  feasible  since  no  one  knows  a  complete  private/public  key-pair.  In  fact,  no 
coalition  of  users  is  able  to  compute  a  public/private  key-pair.  The  only  way  to  “break” 
the  system  appears  to  be  by  subverting  a  SEM.  Thus,  in  the  context  of  IB-mRSA  we 
have  to  assume  that  a  SEM  is  a  fully  trusted  party,  as  opposed  to  semi-trusted  in 
mRSA. 


63 


One  unclear  issue  has  to  do  with  the  existence  of  attacks  on  a  common  modulus 
with  a  large  number  of  public/private  key  pairs.  With  one  public/private  key  pair,  it  is 
widely  believed  that  RSA  encryption  (with  OAEP  padding)  is  secure  against  adaptive 
chosen  ciphertext  attack  [2],  [7].  More  specifically,  such  encryption  is  secure  even  if  the 
attacker  is  allowed  to  employ  a  decryption  oracle  at  will.  In  IB-mRSA  we  introduce  a 
new  attack  model: 

The  adversary  is  allowed  to  freely  choose  e! ,  and  ask  the  decryption/signature 

oracle  to  decrypt/sign  a  chosen  ciphertext/plaintext  with  d!  any  number  of 

times.  (Where  d'  is  the  private  counterpart  of  e!  and  RSA  modulus  is  fixed.) 

We  refer  to  this  type  of  a  decryption  oracle  as  a  multi-key  oracle.  This  oracle  re¬ 
veals  more  information  than  a  traditional  decryption  or  signature  oracle,  however,  it 
does  not  possess  more  secret  information.  The  reason  being  that,  knowing  one  RSA 
private/public  key  pair  is  equivalent  to  knowing  the  factorization  of  n,  which  allows 
one  to  compute  a  private  exponent  for  any  given  public  exponent.  A  SEM  in  IB-mRSA 
can  be  viewed  as  a  multi-key  oracle  in  a  sense  that  “bad”  users  can  act  as  attackers 
and  use  the  SEM  to  decrypt/sign  any  number  of  chosen  messages.  Although  no  formal 
security  proof  is  offered  in  this  paper,  we  were  unable  to  find  any  attacks  in  this  model. 
(Albeit,  it  seems  that  the  security  of  the  multi-key  oracle  is  somehow  tied  to  the  Strong 
RSA  Assumption  [6].) 

Key  Generation  In  Section  3.1,  we  directly  use  the  numerical  value  of  an  email  address 
as  a  public  key.  The  main  requirement  for  an  integer  to  form  a  proper  RSA  public 
exponent  e  is  that  it  should  be  relatively  prime  with  4>(n).  Clearly,  not  all  ASCII  strings 
satisfy  this  requirement. 

Since  we  choose  n  =  (2 p'  +  1)(2 q'  +  1),  we  have  tf>{n )  =  Ap'q' .  Both  p'  and  q' 
are  large  primes  (ca.  511  bits)  while  a  typical  email  address  is  typically  at  most  320 
bits,  which  is  much  smaller  than  p'  and  q' .  In  addition,  note  that  all  email  addresses  are 
converted  into  odd  integers  in  Algorithm  IBE  mRSA.Key.  Thus  the  derived  e  (which  is 
odd)  is  not  divisible  by  any  of:  {2,4,p',  q'}.  In  other  words,  e  is  relatively  prime  with 
4>{n). 

Even  if  a  very  long  email  address  is  used,  the  probability  of  gcd(e,  <j)(n ))  >  1  is 
negligible.  The  reason  is  that  all  odd  integers  which  are  not  relatively  prime  with  !//(/' 
are:  {//,  3  p\  (4  q'  -  l)p' }  and  {q' ,  3  q' , . . . ,  (4 p'  -  l)q'}.  There  are  2(p'  +  q'  -  1) 

such  integers.  Thus,  for  a  random  odd  integer  r  <  4>(n ): 

Pr[gcd{r,  4>{n))  >  1]  =  ^  +  <1,  ,  ^ 

zp  q 

which  is  overwhelmingly  small. 

As  pointed  out  in  [3],  a  secure  RSA  setting  requires  that  the  decryption  key  to  be 
large  enough.  Usually  it  should  be  at  least  larger  than  n°.  5,  which  is  relatively  the  size 
of  p  and  q.  This  is  guaranteed  by  choosing  short  email  address.  For  example,  if  e  is  at 
most  320  bits,  the  corresponding  d  should  be  longer  than  512  bits,  in  case  of  a  1024-bit 
modulus. 
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Forward  Security  One  of  the  motivations  for  research  on  ID-based  cryptosystems  is  to 
provide  forward  security  [1],  A  usual  forward  security  technique  involves  using  a  time- 
variant  parameter  along  with  user  identifier,  such  that  the  derived  key  changes  with 
time,  e.g.,  every  day  or  every  month. 

IB-mRSA  can  provide  forward  security  in  the  same  manner.  Rather  than  comput¬ 
ing  e  from  just  an  email  address,  current  date  can  be  appended.  In  this  case,  the  key 
distribution  process  in  Section  3.1  should  be  revised.  Instead  of  getting  the  signed  and 
encrypted  key  bundle  when  joining  an  organization,  the  user  sends  a  request  to  the  CA 
when  it  received  the  first  encrypted  message  in  the  current  period.  This  causes  the  CA 
to  generate  and  distribute  the  appropriate  keys. 

This  is  clearly  an  expensive  process  since  the  CA  should  be  on-line  and  ready  for 
users’  requests.  In  addition,  the  CA  needs  to  compute  all  non-revoked  keys  in  every 
period.  Thus,  forward  secure  IB-mRSA  is  more  suitable  for  organizations  where  IB- 
mRSA  is  lightly  used  and  there  exists  an  secure  channel  between  users  and  the  CA  to 
protect  key  generation  requests. 

Organization  Certificate  and  User  Certificate  Once  the  common  RSA  modulus  n  and 
the  mapping  function  /()  is  chosen,  the  CA  issues  and  publishes  a  domain  (attribute) 
certificate  which  includes  these  two  values.  In  addition,  the  certificate  also  contains  the 
organization/domain  name  (e.g.  @ics  .  uci  .  edu). 

User  certificates  are,  as  mentioned  before,  optional  in  IB-mRSA.  They  actually 
bridge  IB-mRSA  with  plain  RSA  and  mRSA.  With  the  individual  certificates,  IB-mRSA 
becomes  fully  compatible  with  normal  mRSA.  The  sender  can  get  the  public  key  from 
the  individual  certificate  if  it  trusts  it,  or  rely  on  the  domain  certificate  and  receiver’s 
email  address  to  compute  the  public  key. 

5  Implementation 

To  test  our  assertions  and  gain  experimental  and  practical  experience,  we  implemented 
the  IB-mRSA  scheme.  Our  implementation  includes  a  IB-mRSA  library  as  well  as  a 
fully  functional  email  plug-ins  for  Eudora[12]  and  Microsoft  Outlook[10].  It  is  freely 
available  from  the  following  web  address: 

http : //sconce . ics . uci . edu/SUCSES 

This  implementation,  incidentally,  is  part  of  the  of  the  SUCSES  project  code  re¬ 
lease  and  borrows  much  of  the  code  from  the  mRSA  package.  We  re-used  the  basic 
mRSA  functions,  including  user  and  SEM  bundle  generation  as  well  as  decryption  and 
signature  procedures. 

Our  Eudora  and  Outlook  plug-ins  allow  the  sender  to  encrypt  outgoing  email  to  all 
clients  in  the  same  domain  using  only  one  domain  (organizational)  certificate.  When 
the  user  is  ready  to  send,  the  plug-in  reads  the  recipient’s  email  address  and  looks  up 
the  organization  certificate  by  using  the  domain  name  in  the  email  address.  A  screen 
snapshot  of  the  Eudora  plug-in  is  shown  in  Figure  1 . 

When  an  email  message  encrypted  with  IB-mRSA  is  received,  an  icon  for  IB-mRSA 
is  dislayed  in  the  message  window.  To  decrypt  the  message,  the  user  just  clicks  on  the 
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Fig.  1.  Eudora  IBE  Plugin 


IB-mRSA  icon.  The  plug-in  then  contacts  the  user’s  SEM  to  get  a  partial  decrypted 
message  (provided  the  user  is  not  revoked).  This  is  basically  the  same  process  as  plain 
mRSA  [4], 

6  Performance 

When  plain  RSA  is  used  for  encryption,  the  public  encryption  exponent  e  is  typically  a 
small  integer  with  only  a  few  bits  set  to  1.  One  example  is  the  popular  OpenSSL  toolkit 
[11]  which  uses  65,  537  as  the  default  public  key  value  for  RSA  certificates.  Encryption 
with  such  small  exponents  can  be  accelerated  with  specialized  algorithms  for  modular 
exponentiation.  However,  in  identity-based  systems,  there  is  no  such  luxury  of  choosing 
special  exponents.  Therefore,  e  is  a  larger  integer  with  likely  higher  number  of  1  bits. 


Keys 

RSA  Modulus  1Kb 

RSA  Modulus  2Kb 

RSA  Modulus  4Kb 

65,537 

2.3  ms 

3.6  ms 

11.7  ms 

xhding@isi.edu 

2.8  ms 

9.5  ms 

32.1  ms 

Alice.Smith@ics.uci.edu 

4.8  ms 

15.5  ms 

53.7  ms 

Table  1.  Performance  Comparison  of  Different  Encryption  Keys 


We  ran  some  simple  tests  to  measure  the  cost  of  IB-mRSA  encryption  for  public 
keys  derived  from  email  addresses.  The  encryption  was  tested  using  Linux  2.4  version 
of  OpenSSL  on  an  800MHz  PHI  workstation.  In  our  tests,  we  used:  1)  “default”  en¬ 
cryption  exponent  65,  537  and  2)  two  other  exponents  derived  from  different  email  ad¬ 
dresses.  Lor  each  key,  we  encrypted  the  same  message  one  thousand  times  and  obtained 
the  average.  The  results  are  depicted  in  Table  1 . 
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(',From  the  results  in  Table  1,  we  note  that  encryption  with  email  address-derived 
keys  does  not  introduce  significant  added  overhead.  Although  the  IB-mRSA  encryption 
overhead  increases  as  the  RSA  modulus  size  grows,  it  is  somewaht  negligible  for  1024- 
bit  modulus  (which  is  currently  the  most  common  size). 

The  decryption  cost  for  IB-mRSA  is  identical  to  mRSA.  The  performance  of  mRSA 
has  been  reported  on  by  Boneh,  et  al.  in  [4],  For  example,  a  1024-bit  mRSA  decryp¬ 
tion  costs  around  30ms  on  an  800  MHz  PHI,  as  compared  to  7.5ms  for  plain  RSA  on 
the  same  platform.  We  note  that  this  is  still  much  cheaper  than  90ms  that  is  needed  for 
Boneh/Frnklin  IBE  decryption  (for  1024  bits  of  security  on  the  same  hardware  plat¬ 
form). 

7  IB-mRSA  versus  Boneh/Franklin  IBE 

Recently,  Boneh  and  Franklin  developed  a  novel  and  elegant  identity-based  encryption 
system  (IBE)  based  on  Weil  Pairing  [5],  IBE  represents  a  significant  advance  in  cryp¬ 
tography  since  the  problem  that  it  solved  has  been  open  for  many  years.  However,  IBE 
does  not  provide  revocation  of  users’  security  capabilities.  This  is  natural  since  it  aims 
to  avoid  the  use  of  certificates  in  the  course  of  public  key  encryption.  On  the  other  hand, 
revocation  is  often  necessary  and  even  imperative. 

The  only  way  to  obtain  revocation  in  IBE  is  to  require  fine-grained  time-dependent 
public  keys,  e.g.,  public  keys  derived  from  identifiers  combined  with  time-  or  date- 
stamps.  This  has  an  unfortunate  consequence  of  having  to  periodically  re-issue  all  pri¬ 
vate  keys  in  the  system.  Moreover,  these  keys  must  be  (again,  periodically)  securely 
distributed  to  individual  users.  Therefore,  the  Public  Key  Generator  (PKG,  in  IBE’s 
parlance)  must  be  on-line  much  of  the  time,  or,  at  least,  very  often.  Consequently,  we 
observe  that,  when  IBE  is  used  to  provide  fine-grained  revocation,  a  PKG  is,  for  all 
practical  purposes,  equivalent  to  a  SEM  in  mRSA  and  IB-mRSA. 

Our  conclusion  is  that,  in  functional  terms,  IB-mRSA  seems  to  offer  security  equiv¬ 
alent  to  IBE  (when  the  latter  provides  fine-grained  revocation).  This  is  because  compro¬ 
mise  of  a  PKG  in  IBE  results  in  a  total  system  break.  The  same  happens  upon  a  SEM 
compromise  in  IB-mRSA.  Moreover,  IB-mRSA  offers  some  practical  advantages  over 
IBE. 

First,  IB-mRSA  is  fully  compatible  with  plain  RSA  if  (optional)  individual  certifi¬ 
cates  are  used.  Thus,  it  offers  a  smooth  and  natural  transition  from  ID-based  to  normal 
cryptography.  Also,  IB-mRSA  (which  takes  roughly  4-5  times  less  efficient  than  plain 
RSA)  offers  significantly  better  performance  than  IBE. 

8  Future  Work  and  Summary 

In  this  paper,  we  described  a  simple,  secure  and  efficient  IB-mRSA  scheme.  IB-mRSA 
combines  the  convenience  of  identity-based  encryption  (thus  greatly  reducing  the  need 
for  public  key  certificates)  with  the  functionality  of  mediated  RSA  which  provides  fine¬ 
grained  revocation. 

IB-mRSA  allows  the  sender  (encryptor)  to  skip  the  costly  checking  of  individual 
public  key  certificates.  The  tight  control  over  users’  security  capability  is  inherited  from 
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mediated  RS  A  mechanism  since  the  decryption  protocol  for  IB-mRSA  is  essentially  the 
same  as  in  mRSA.  Furthermore,  IB-mRSA  can  be  easily  be  extended  to  provide  forward 
security. 

Several  issues  remain  for  future  work.  First,  we  have  not  provided  a  formal  proof 
that  RSA  (with  OAEP  padding)  is  secure  against  adaptive  chosen  ciphertext  attack  if 
the  decryption  oracle  offers  replies  for  multiple  private  keys  with  the  same  modulus. 
We  also  need  to  investigate  alternative  mapping  functions  in  order  to  speed  up  the  en¬ 
cryption  with  derived  public  keys. 
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Abstract 

This  paper  explores  practical  and  conceptual  impli¬ 
cations  of  using  Server- Aided  Signatures  (SAS).  SAS 
is  a  signature  method  that  relies  on  partially-trusted 
servers  for  generating  public  key  signatures  for  regu¬ 
lar  users.  Besides  its  two  primary  goals  of  1)  aiding 
small,  resource-limited  devices  in  computing  heavy¬ 
weight  (normally  expensive)  digital  signatures  and  2) 
fast  certificate  revocation,  SAS  also  offers  signature 
causality  and  has  some  interesting  features  such  as 
built-in  attack  detection  for  users  and  DoS  resistance 
for  servers. 

1  Introduction 

Digital  signatures  represent  a  basic  building  block  for 
many  secure  applications.  Their  uses  range  from  elec¬ 
tronic  commerce  transactions  to  secure  email,  secure 
content  (code,  video,  audio)  distribution  and  other, 
more  specialized  applications  such  as  document  no¬ 
tarization.  Traditionally,  digital  signatures  are  based 
on  asymmetric  (public  key)  cryptographic  techniques 
which,  at  least  in  some  settings,  makes  them  compu¬ 
tationally  expensive. 

While  digital  signatures  are  rapidly  becoming  ubiq¬ 
uitous,  one  of  the  major  recent  trends  in  computing 
has  been  towards  so-called  “smart”  devices,  such  as 
PDAs,  cell  phones  and  palmtops.  Although  such  de¬ 
vices  come  in  many  shapes  and  sizes  and  are  used 
for  a  variety  of  purposes,  they  tend  to  have  one  fea¬ 
ture  in  common:  limited  computational  capabilities 
and  equally  limited  power  (as  most  operate  on  bat¬ 
teries)  .  This  makes  them  ill-suited  for  complex  cryp¬ 
tographic  computations  such  as  large  number  arith¬ 
metic  present  in  virtually  all  public  key  constructs. 

Furthermore,  in  many  envisaged  setting,  such  as 
cell  telephony  and  wireless  web  access,  personal  de¬ 
vices  are  in  constant  contact  with  a  fixed,  wired  in¬ 


frastructure.  Consequently,  access  to  more  powerful 
(in  terms  of  both  CPU  speed  and  not  dependent  on 
batteries)  computing  platforms  is  available  to  end- 
users. 

At  the  same  time,  increased  use  of  digital  signa¬ 
tures  accentuates  the  need  for  effective  revocation 
methods.  Revocation  of  cryptographic  credentials 
and  certificates  has  been  an  issue  for  a  long  time. 
However,  only  now  the  problem  is  becoming  truly 
visible,  e.g.,  the  recent  Verisign  fiasco  where  a  wrong 
certificate  was  issued  (ostensibly  to  Microsoft)  and 
its  subsequent  revocation  was  both  slow  and  painful. 
Furthermore,  current  CRL-based  revocation  methods 
scale  poorly  and  are  not  widely  used  in  practice.  For 
example,  most  current  web  browsers  do  not  bother 
checking  CRLs;  only  the  upcoming  Windows  XP  has 
some  rudimentary  CRL-checking  facilities. 

Effective  revocation  not  only  useful  but  vital  in 
some  organizational  settings  (e.g.,  government  and 
military)  where  digital  signatures  are  used  on  impor¬ 
tant  electronic  documents  and  in  accessing  critical 
resources.  Consider  a  situation  when  a  trusted  user 
(Alice)  does  something  that  warrants  immediate  re¬ 
vocation  of  her  security  privileges.  Alice  might  be 
fired,  transferred  or  she  may  suspect  that  her  private 
key  has  been  compromised.  Ideally  -  immediately 
following  revocation  -  no  one  should  be  able  to  per¬ 
form  any  cryptographic  operations  involving  Alice’s 
certificate,  i.e.,  sign  with  her  private  key. 

In  addition,  when  a  cryptographic  certificate  is  re¬ 
voked  (or  simply  expires)  digital  signatures  generated 
prior  to  revocation  (or  expiration)  may  need  to  re¬ 
main  valid.  This  is  difficult  to  achieve  with  current 
revocation  methods  since  CRLs  (and  similar  meth¬ 
ods  like  OCSP  [1])  do  not  provide  a  secure  means  of 
distinguishing  between  pre-  and  post-revocation  sig¬ 
nature  activity.  The  only  way  to  do  so  is  by  using 
a  secure  timestamping  service  for  all  signatures.  Al¬ 
though  a  secure  timestamping  service  may  provide  a 
secure  means  of  distinguishing  between  pre-  and  post- 
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revocation  signature,  it  has  not  been  widely  adopted 
due  to  its  prohibitive  cost.  Finally,  we  note  that  com¬ 
promise  of  a  private  key  can  lead  to  an  unlimited 
number  of  fraudulent  signatures  being  generated  and 
distributed  by  the  adversary.  As  often  happens  in 
the  event  of  compromise,  contact  with  the  revocation 
authority  (CA)  may  not  be  immediate,  e.g.,  in  a  spo¬ 
radically  connected  wireless  network.  Therefore,  it  is 
important  to  find  a  way  to  limit  potential  damage. 

In  this  paper  we  present  a  method,  called  Server- 
Aided  Signatures  (SAS),  that  is  designed  to  addresses 
the  aforementioned  issues.  Its  goals  are  three-fold: 

1.  Assist  small,  limited-power  devices  in  computing 
digital  signatures 

2.  Provide  fast  revocation  of  signing  capability 

3.  Limit  damage  from  potential  compromise 

The  rest  of  the  paper  is  organized  as  follows.  Next 
section  provides  a  brief  synopsis  of  our  work  and  its 
contributions.  Section  5  describes  the  SAS  method  in 
greater  detail;  it  is  followed  by  the  security  analysis 
in  Section  6.  Denial  of  service  issues  are  addressed 
in  Section  7.  Then,  implementation  and  performance 
measurements  are  discussed  in  Section  8.  The  paper 
concludes  with  the  summary  of  benefits  and  draw¬ 
backs  of  SAS. 

2  Synopsis 

The  signature  method  (SAS)  discussed  here  is  based 
largely  on  a  weak  non-repudiation  technique  due 
to  Asokan  et  al.  [2].  The  most  notable  feature 
of  the  SAS  method  is  its  on-line  nature.  Specifi¬ 
cally,  each  SAS  signature  is  generated  with  the  aid 
of  a  partially-trusted  server  called  a  SEM  (short  for 
SEcurity  Mediator) .  This  feature  can  be  viewed  as  a 
mixed  blessing.  Although  it  offers  a  number  of  ben¬ 
efits  which  are  summarized  below,  the  requirement 
for  on-line  help  for  each  signature  is  clearly  a  burden. 
We  discuss  the  drawbacks,  both  real  and  perceived, 
in  Section  9. 

Informally,  a  SAS  signature  is  computed  as  follows 
(see  also  Figure  1): 

•  First,  a  prospective  signer  (Alice)  contacts  her 
SEM  and  provides  the  data  to  be  signed  as  well 
as  a  one-time  ticket. 

•  SEM  checks  Alice’s  revocation  status  and,  if  not 
revoked,  computes  a  half-signature  over  the  data 
as  well  as  other  parameters  (including  the  one¬ 
time  ticket).  SEM  then  returns  the  results  to 
Alice. 


•  Alice  verifies  SEM’s  half-signature  and  produces 
her  own  half-signature.  Put  together,  the  two  re¬ 
spective  half-signatures  constitute  a  regular,  full 
SAS  signature.  This  signature  is  accompanied 
by  SEM’s  and  Alice’s  certificates. 

The  two  half-signatures  are  inter-dependent  and  each 
is  worthless  in  and  of  itself.  This  is  despite  the  SEM’s 
half-signature  being  a  traditional  digital  signature:  in 
the  context  of  SAS,  a  traditional  signature  computed 
by  a  SEM  is  not,  by  itself,  a  SAS  signature.  The  half¬ 
signature  computed  by  a  user  (Alice,  in  our  example) 
is  actually  a  one-time  signature  [3]. 


Figure  1:  SAS  architecture 


Verifying  a  SAS  signature  is  easy:  verifier  (Bob) 
obtains  the  signature  and  verifies  the  two  halves  along 
with  the  two  accompanying  certificates. 

The  main  idea  is  that  a  SEM,  albeit  only  partially 
trusted,  is  more  secure,  and  much  more  capable  (in 
terms  of  CPU  and  power  consumption)  than  an  aver¬ 
age  user.  It  can  therefore  serve  a  multitude  of  users. 
Also,  because  of  its  “superior”  status,  SEM  is  much 
less  likely  to  be  revoked  or  compromised.  Since  a 
signer  (Alice)  is  assumed  to  have  much  less  comput¬ 
ing  power  then  a  SEM,  the  latter  performs  the  bulk  of 
the  computation,  whereas,  Alice  does  comparatively 
little  work.  In  the  event  that  Alice’s  certificate  is  re¬ 
voked,  the  SEM  simply  refuses  to  perform  any  further 
signatures  on  Alice’s  behalf.  (See  Figure  1.)  Thus, 
revocation  is  both  implicit  and  fast.  However,  this 
does  not  obviate  the  need  for  Certificate  Revocation 
Lists  (CRLs)  since  Alice’s  certificate  may  be  revoked 
after  some  fraudulent  signatures  have  been  already 
generated.  A  CRL  may  still  be  necessary  to  convey 
to  all  verifiers  the  exact  time  of  revocation  and  hence 
to  sort  out  pre-  and  post-revocation  signatures. 

The  general  system  model  of  SAS  is  a  good  fit  for 
many  mobile  settings.  For  example,  as  mentioned  in 
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Section  1,  cell  phones  are  only  usable  when  in  touch, 
via  a  nearby  base  station,  with  a  fixed  infrastructure. 
Each  phone-call  requires  communication  with  the  in¬ 
frastructure.  This  communication  can  be  overloaded 
to  piggyback  SAS  protocol  messages. 

3  Related  Work 

The  SAS  method  is  based  on  a  weak  non-repudiation 
technique  proposed  by  Asokan  et  al.  in  [2].  In  very 
general  terms,  SAS  is  an  instantiation  of  a  mediated 
cryptographic  service.  Recent  work  by  Boneh  et  al. 
[4]  on  mediated  RSA  (mRSA)  is  another  example  of 
mediated  cryptography.  mRSA  provides  fast  revoca¬ 
tion  of  both  signing  and  decryption  capability.  How¬ 
ever,  the  computation  load  on  the  client  end  is  in¬ 
creased  in  mRSA,  which  is  something  that  SAS  aims 
to  minimize. 

In  [5]  Reiter  and  McKenzie  propose  a  the  same  ad¬ 
ditive  splitting  technique  to  improve  the  security  for 
portable  devices  where  the  private-key  operations  are 
password-protected.  Recently,  they  also  proposed  an¬ 
other  scheme  for  the  more  challenging  problem  of  me¬ 
diated  (2-party)  DSA  signatures  [6].  Ganesan[7]  also 
exploited  (earlier,  in  1996)  the  same  idea  for  improv¬ 
ing  Kerberos  security  as  part  of  the  Yaksha  system. 

Another  way  to  look  at  SAS  is  as  an  instantiation  of 
“hybrid”  multi-signatures  [8].  Viewed  more  broadly, 
the  SAS  method  can  be  included  in  the  more  general 
framework  of  threshold  cryptography  [9]  and  secure 
multi-party  computation[10]. 

There  is  also  much  related  work  on  the  topic  of  cer¬ 
tificate  revocation;  including  CRLs,  A-CRLs,  CRTs, 
2-3  lists  and  skip-lists.  This  is  reviewed  in  more  detail 
in  Appendix  B. 

4  Background 

In  this  section  we  go  over  some  preliminaries  neces¬ 
sary  for  the  remainder  of  the  paper. 

4.1  Hash  Functions 

Informally,  a  one-way  function  /()  is  a  function 
such  that,  given  an  input  string  x  it  is  easy  to  com¬ 
pute  /( x),  whereas,  given  a  randomly  chosen  y,  it 
is  computationally  infeasible  to  find  an  x  such  that 
f(x)  =  y.  A  one-way  hash  function  h()  is  a  one-way 
function  that  operates  on  arbitrary-length  inputs  to 
produce  a  fixed  length  digest.  If  y  =  h(x),  y  is  com¬ 
monly  referred  to  as  the  hash  of  x  and  x  is  referred 
to  as  the  pre-image  of  y.  A  one-way  hash  function 


h()  is  said  to  be  collision-resistant  if  it  is  compu¬ 
tationally  hard  to  find  any  two  distinct  input  strings 
x,x'  such  that  h{x)  =  h(x'). 

Several  secure  and  efficient  collision-resistant  one¬ 
way  hash  functions  have  been  proposed,  e.g.,  SHA  or 
MD5  [11].  In  the  rest  of  the  paper,  h()  denotes  a 
collision-resistant  one-way  hash  function. 

A  collision-resistant  one-way  hash  function  can  be 
recursively  applied  to  an  input  string.  The  notation 
hl(x )  is  the  result  of  applying  h()  i  times  starting 
with  the  input  x,  that  is: 

hl(x)  =  h(h(. . .  h(h(x)) . . .)) 

s - v - ' 

i  times 

Recursive  application  results  in  a  hash-chain  gener¬ 
ated  from  the  original  input: 

x  =  h°(x),h1(x),  ...,  hn(x) 

Hash  chains  have  been  widely  used  since  early  1980-s 
starting  with  the  well-known  Lamport’s  method  [12]. 

4.2  Model  and  Notation 

We  distinguish  among  3  types  of  entities: 

•  Regular  Users  -  entities  who  generate  and  verify 
SAS  signatures. 

•  Security  Mediators  (SEMs)  -  partially-trusted 
entities  assisting  regular  users  in  generating  SAS 
signatures. 

•  Certification  Authorities  ( CAs)  -  trusted  off-line 
entities  that  issue  certificates  and  link  the  iden¬ 
tities  of  regular  users  with  SEMs. 

SEMs  and  CAs  are  verifiable  third  parties  from  the 
users’  point  of  view. 

All  participants  agree  on  a  collision-resistant  one¬ 
way  hash  function  family  Ti  and  a  digital  signature 
scheme.  In  SAS,  the  latter  is  fixed  to  be  the  RSA 
scheme  [13].  Furthermore,  each  signer  (Alice)  selects 
a  “personalized”  hash  function  h,A§  G  H.  In  essence, 
HaO  can  be  thought  of  as  a  keyed  hash  (e.g.,  [14]) 
with  a  known  key  set  to  the  identity  of  the  signer. 
When  applied  recursively,  we  also  include  the  index 
of  the  hash  function  link  in  each  computation,  i.e., 
hlA(x)  can  be  thought  of  as  a  keyed  hash  where  the 
known  key  is  the  concatenation  of  the  signer’s  iden¬ 
tity  (Alice)  and  the  index  of  the  link,  i. 

In  order  to  minimize  computation  overhead  for  reg¬ 
ular  users,  h()  must  be  efficient  and  the  digital  sig¬ 
nature  scheme  must  be  efficient  for  verifiers.  (This 
is  because,  as  will  be  seen  below,  verification  is  done 
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by  regular  users,  whereas,  signing  is  done  by  much 
more  powerful  SEMs.)  SHA  and  MD5  are  reason¬ 
able  choices  for  the  former,  while  RSA  [13]  satisfies 
the  efficient  verification  requirement  when  used  with 
a  small  exponent  such  as  3,  17  or  65,537. 

4.3  Communication  Channel 

We  assume  that  the  communication  channel  between 
each  user  and  a  SEM  is  reliable  (but  neither  pri¬ 
vate  nor  authentic).  Reliability  of  the  channel  implies 
that  the  underlying  communication  system  provides 
sufficient  error  handling  to  detect,  with  overwhelm¬ 
ing  probability,  all  corrupted  packets.  One  way  to 
achieve  this  is  by  having  each  protocol  packet  ac¬ 
companied  by  its  hash.  Furthermore,  timeouts  and 
retransmissions  are  likewise  handled  by  the  commu¬ 
nication  system  with  the  assumption  that  a  packet 
eventually  gets  through. 

We  note  that,  even  if  the  user  is  disconnected  from 
the  network1  after  sending  a  signature  request  to 
its  SEM  and  before  receiving  a  reply,  the  user  will 
eventually  obtain  the  correct  reply  (if  the  request 
ever  reached  the  SEM)  whenever  the  communication 
channel  is  re-established.  Specifically,  as  described  in 
the  next  section,  a  SEM  always  replies  with  the  last 
signature  it  computed  for  a  given  user. 

5  SAS  Description 

We  now  turn  to  the  detailed  protocol  description. 

5.1  Setup 

To  become  a  SAS  signer,  Alice  first  generates  a  se¬ 
cret  quantity  SKa  randomly  chosen  from  the  range 
of  hA().  Starting  with  this  value,  Alice  computes  a 
hash-chain: 

{  SK°a,  SK\, . . .  SKa~1,SKa  }  where 

SKjA  =  hjA{SK°A)  =  hA{SKjA1)  for  1  <  j<  n 

The  last  value,  SKA,  is  referred  to  as  Alice’s  SAS 
root  key.  It  subsequently  enables  Alice  to  produce 
(n  —  1)  SAS  signatures. 

Each  SEM  is  assumed  to  have  a  secret/public  RSA 
key-pair  (SKsem,  PKsem)  of  sufficient  length.  (We 
use  the  notation  [ x\sem  to  denote  SEM’s  signature  on 
string  x).  Each  CA  also  has  its  own  key-pair  much 
like  any  traditional  CA.  In  addition  to  its  usual  role 

1This  can  happen  if  a  wireless  device,  e.g.,  a  cell  phone,  is 
momentarily  out  of  range  of  any  base  station. 


of  issuing  and  revoking  certificates  a  CA  also  main¬ 
tains  a  mapping  between  users  and  SEMs  that  serve 
them.  This  relationship  is  many  to  one,  i.e.,  a  SEM 
serves  a  multitude  of  users.  Exactly  how  many  de¬ 
pends  on  many  factors,  such  as:  SEM’s  hardware 
platform,  average  user  signature  request  frequency, 
network  characteristics,  etc.  We  expect  the  number 
and  placement  of  SEMs  in  an  organizational  network 
to  closely  resemble  that  of  OCSP  Validation  Agents 
(VAs)  [1], 

In  order  to  obtain  a  SAS  certificate  CertA,  Alice 
composes  a  certificate  request  and  submits  it  to  the 
CA  via  some  (usually  off-line)  channel.  Alice’s  SAS 
certificate  has,  for  the  most  part,  the  same  format 
as  any  other  public  key  certificate;  it  includes  values 
such  as  the  holder’s  distinguished  name,  organiza¬ 
tional  data,  expiration/ validity  dates,  serial  number, 
public  token  key,  and  so  forth.  Additionally,  a  SAS 
certificate  contains  two  other  fields: 

1.  Maximum  number  of  signatures  n  that  the  en¬ 
closed  public  key  can  be  used  to  generate,  and 

2.  Distinguished  name  and  certificate  serial  number 
of  the  SEM  serving  the  certificate  holder. 

Once  issued,  Alice’s  SAS  certificate  CertA  can  be 
made  publicly  available  via  a  directory  service  such 
as  LDAP  [15]. 

5.2  SAS  Signature  Protocol 

The  protocol  proceeds  as  follows.  (In  the  initial 
protocol  run  the  signature  counter  i  =  n  —  1;  it 
is  decremented  after  each  run.  This  counter  is 
maintained  by  both  SEM  and  Alice.) 

Step  1.  Alice  starts  by  sending  a  request  containing: 
[Alice,  m,  i,  SKa]  to  its  assigned  SEM.  If  Alice  does 
not  wish  to  reveal  the  message  to  the  SEM,  m  can  be 
replaced  with  a  suitable  keyed  (or,  more  accurately, 
randomized)  hash  such  as  the  well-known  HMAC 
[14].  (In  that  case,  Alice  would  send  HMACr(m) 
where  r  is  a  one-time  random  value  used  a  key  in  the 
HMAC  computation.) 

Alice  may  also  (optionally)  enclose  her  SAS 
certificate. 

Step  2.  Having  received  Alice’s  request,  SEM 
obtains  CertA  (either  from  the  request  or  from 
local  storage)  and  checks  its  status.  If  revoked, 
SEM  replies  with  an  error  message  and  halts  the 
protocol.  Otherwise,  SEM  compares  the  signature 
index  in  the  request  to  its  own  signature  counter.  In 
case  of  a  mismatch,  SEM  replies  to  Alice  with  the 
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lowest-numbered  half-signature  produced  in  the  last 
protocol  run  and  aborts. 

Next,  SEM  proceeds  to  verify  the  received  public  key 
( SK\ )  based  on  Alice’s  SAS  root  key  contained  in 
the  certificate.  (If  this  is  Alice’s  initial  request,  the 
signature  counter  is  initialized  to  Having  received 
Alice’s  request,  SEM  obtains  Cert  a  (either  from  the 
request  or  from  local  storage)  and  checks  its  status. 
If  revoked,  SEM  replies  with  an  error  message  and 
halts  the  protocol.  Otherwise,  SEM  compares  the 
signature  index  in  the  request  to  its  own  signature 
counter.  In  case  of  a  mismatch,  SEM  replies  to  Alice 
with  the  lowest-numbered  half-signature  produced 
in  the  last  protocol  run  and  aborts.  Specifically, 
SEM  checks  that  hr^~x(SKA)  =  SKA.  In  case  of 
a  mismatch,  SEM  replies  to  Alice  with  the  last 
recorded  half-signature  and  aborts  the  protocol. 

Next,  SEM  signs  the  requested  message  with  its 
private  key  to  produce:  [CertA,  m,  i,  SKa]sem. 
Other  attributes  may  also  be  included  in  SEM’s 
half-signature,  e.g.,  a  timestamp.  SEM  decrements 
Alice’s  signature  counter,  records  the  half-signature 
and  returns  the  latter  to  Alice. 

In  the  above,  SEM  assures  that  -  for  a  given  SAS 
certificate  -  exactly  one  signature  is  created  for  each 
[i,  SK\ ]  tuple.  We  refer  to  this  property  as  the  SAS 

Invariant. 

Step  3.  Alice  (who  is  assumed  to  be  in  possession 
of  SEM’s  certificate  at  all  times)  verifies  SEM’s  half¬ 
signature,  records  it  and  decrements  her  signature 
counter.  If  SEM’s  half-signature  fails  verification 
or  its  attributes  are  wrong  (e.g.,  it  signs  a  different 
message  than  in  or  includes  an  incorrect  signature 
counter  j  /  i),  Alice  aborts  the  protocol  and 

concludes  that  a  hostile  attack  has  occurred.2  (See 
Section  7  below.) 

Finally,  Alice’s  SAS  signature  on  message  m  has  the 
following  format: 

SIGi  =  [CertA,  m,  i,  SK\]sem ,  SK^1 

The  second  part,  namely  SKlAl ,  is  Alice’s  half¬ 
signature.  As  mentioned  earlier,  it  is  actually  a 
one-time  signature:  Ha(SKza  )  =  SK\. 

Note  that  Alice  must  use  her  one-time  keys  in  strict 
sequence.  In  particular,  Alice  must  not  request  a 

“Our  communication  channel  assumption  rules  out  noil- 
malicious  packets  errors. 


SEM  half-signature  using  SKlAl  unless,  in  the  last 
protocol  run,  she  obtained  SEM’s  half-signature  con¬ 
taining  SK\. 

5.3  SAS  Signature  Verification 

SAS  signature  verification  comes  in  two  flavors :  light 
and  full.  The  particular  choice  depends  on  the  veri¬ 
fier’s  trust  model.  Recall  that  the  philosophy  of  SAS 
is  based  on  much  greater  (yet  not  unconditional)  trust 
placed  in  a  SEM  than  in  a  regular  user.  If  a  verifier 
(Bob)  fully  subscribes  to  this,  i.e.,  trusts  a  SEM  more 
than  Alice,  he  can  chose  light  verification.  Otherwise, 
if  Bob  is  equally  suspicious  of  SEMs  as  of  ordinary 
users,  he  can  choose  full  verification. 

Light  verification  involves  the  following  steps: 

1.  Obtain  and  verify3  CertsEM 

2.  Verify  SEM’s  RSA  half-signature: 
[CertA,  m,  i,  SK'a[sem 

3.  Verify  Alice’s  half-signature:  Ha{SK1a1)  = 
SK\ 

Full  verification  requires,  in  addition: 

4.  Verify  Cert  a 

5.  Check  that  i  <  n 

6.  Verify  Alice’s  SAS  root  key:  hnA\SK\)  =  SKr\ 

Note  that  light  verification  does  not  involve  check¬ 
ing  Alice’s  SAS  certificate.  Although  this  may  seem 
counter-intuitive,  we  claim  that  SAS  signature  for¬ 
mat  (actually  SEM’s  half-signature)  already  includes 
CertA  as  a  signed  attribute.  Therefore,  for  a  verifier 
who  trusts  the  SEM,  step  2  above  implicitly  verifies 
CertA- 

It  is  easy  to  see  that,  owing  to  the  trusted  nature 
of  a  SEM  and  the  SAS  Invariant,  light  verification 
is  usually  sufficient.  However,  if  a  stronger  property 
(such  as  non-repudiation)  is  desired,  full  verification 
may  be  used. 

5.4  State  and  Registration 

As  follows  from  the  protocol  description  above,  both 
Alice  and  the  SEM  maintain  state.  Alice’s  SAS  state 
amounts  to  the  following: 

CertA,  Cert-sEM,  SI<a,  h  {SIGn, ...,  S7G,n_J_i} 

3  This  may  be  done  infrequently. 
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The  first  three  values  are  self-explanatory.  The  fourth 
is  Alice’s  current  signature  counter,  (i),  and  the  rest 
is  the  list  of  previously  generated  signatures  for  the 
same  Cert  a-  The  state  kept  by  the  SEM  (for  each 
user)  is  similar: 

Cert A ,  i,  { SIGn , S'/Gn_i_  1} 

The  amount  of  state  might  seem  excessive  at  first, 
especially  considering  that  some  users  might  be  on 
small  limited-storage  devices.  There  are  some  opti¬ 
mizations,  however.  First,  we  note  that  Alice  can  pe¬ 
riodically  off-load  her  prior  signatures  to  some  other 
storage  (e.g.,  to  a  workstation  or  a  PC  when  the  PDA 
is  charging).  Also,  it  is  possible  to  drastically  re¬ 
duce  state  maintenance  for  both  users  and  SEMs  if 
successive  signatures  are  accumulated.  For  example, 
each  SEM’s  half-signature  can  additionally  contain 
the  hash  of  the  last  prior  SAS  signature.  This  opti¬ 
mization  results  in  storage  requirements  comparable 
to  those  of  a  traditional  signature  scheme. 

Registration  in  SAS  can  be  done  either  off-  or  on¬ 
line.  In  the  off-line  case,  SEM  obtains  Alice’s  SAS 
certificate  via  manual  (local  or  remote)  installation  by 
an  administrator  or  by  fetching  it  from  the  directory 
service.  To  register  on-line,  Alice  simply  includes  her 
SAS  certificate  as  an  optional  field  in  the  initial  SAS 
signature  request  to  the  SEM.  Before  processing  the 
request  as  described  above,  the  SEM  checks  if  the 
same  certificate  is  already  stored.  If  not,  it  installs  in 
the  certificate  database  and  creates  a  new  user  entry. 
(See  Figure  2.) 


Incoming  user  Incoming  admin 

request  request 


Figure  2:  SEM  architecture 


6  Analysis 

We  now  consider  the  efficiency  and  security  aspects 
of  the  SAS  signature  method. 

6.1  Efficiency 

The  cost  of  our  signature  protocol  can  be  broken  up 
as  follows: 

1.  Network  overhead:  round-trip  delay  between  Al¬ 
ice  and  SEM 

2.  SEM  computation:  signature  computation  plus 
other  overhead  (including  hash  verification  of 
user’s  one-time  public  key,  database  processing, 
etc.) 

3.  User  computation:  verification  of  the  SEM  half¬ 
signature  and  other  (commitment  to  storage) 
overhead. 

Clearly,  (1)  and  (3)  are  extra  steps  as  compared  with 
a  traditional  signature  method.  The  extra  cost  of 
light  signature  verification  (referring  to  the  steps  in 
the  previous  section)  is  only  in  Step  3  which  consists 
of  a  single  hash  operation.  Full  verification  costs  an 
additional  certificate  validation  (Step  4)  as  well  as 
(n  —  i)  hash  operations  in  Step  5. 

6.2  Security  Analysis 

We  claim  that  the  SAS  signature  method  achieves  the 
same  security  level  as  a  traditional  digital  signature 
scheme  if  SAS  signature  and  verification  protocols  are 
executed  correctly.  Due  to  space  limitations,  we  only 
present  an  informal  security  analysis. 

To  forge  a  SAS  signature,  an  adversary  can  at¬ 
tempt  to: 

TYPE  1:  forge  a  SEM’s  half-signature  (i.e.,  an  RSA 
signature)  or 

TYPE  2:  find  a  quantity  SKA  such  that 
H(SKA)  =  SKA.  Recall  that  SK\  is  in¬ 
cluded  in  SEM’s  half-signature. 

Clearly,  a  TYPE  1  attack  is  an  attack  on  the  un¬ 
derlying  signature  scheme,  i.e.,  RSA,  and,  as  such,  is 
not  specific  to  the  SAS  method.  Therefore,  we  only 
consider  TYPE  2  attacks.  However,  finding  SI\*A 
implies  a  successful  attack  on  either  the  collision- 
resistance  or  the  one-wayness  property  of  the  under¬ 
lying  hash  function  JiaQ-  Even  we  were  to  allow 
the  possibility  of  the  adversary  mounting  a  success¬ 
ful  TYPE  2  attack,  the  scheme  remains  secure  if  full 
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verification  is  used.  (Recall  that  full  verification  in- 

? 

eludes  not  only  checking  H(SKA)  =  SKA  but  also 
hnA~\SK\)  =  SK\.) 

We  observe  that,  in  any  practical  digital  signature 
scheme,  a  collision-resistant  one-way  hash  function 
is  first  applied  to  the  message  in  order  to  produce 
a  fixed-length  digest  which  is  then  signed.  Hence, 
a  successful  TYPE  2  attack  on  a  SAS  signature  is, 
at  the  same  time,  an  attack  on  the  digital  signature 
scheme. 

6.3  Disputes 

In  case  of  a  dispute  between  a  signer  (Alice)  and  a 
verifier  (Bob),  the  latter  submits  the  disputed  SAS 
signature  to  an  unbiased  arbitrator  who  starts  by  ver¬ 
ifying  the  following: 

•  Alice’s  and  SEM’s  certificates  are  valid  and  cer¬ 
tified  by  a  C A. 

•  SEM’s  half-signature  is  valid. 

•  Alice’s  one-time  key  is  a  hash  pre-image  of  the 
value  in  SEM’s  half-signature. 

•  The  SAS  root  key  in  Cert  a  can  be  derived  from 
the  one-time  public  key  by  repeated  hashing. 

This  is  essentially  the  full  SAS  signature  verification 
as  described  earlier.  If  any  of  the  above  steps  fails, 
the  arbitrator  rules  in  Alice’s  favor.  Otherwise,  Bob 
wins  the  dispute. 

Assuming  the  above  procedure  succeeds,  Alice  is 
asked  to  produce  a  different  SAS  signature  with  the 
same  one-time  key  (i.e. ,  same  one-time  signature).  If 
Alice  can  come  up  with  such  a  signature  (meaning 
that  the  message  signed  is  different  from  the  one  in 
the  disputed  signature),  the  arbitrator  concludes  that 
Alice’s  SEM  cheated  or  was  compromised.  This  con¬ 
clusion  is  based  on  the  apparent  violation  of  the  SAS 
Invariant.  If  Alice  fails  to  produce  a  different  signa¬ 
ture,  the  arbitrator  concludes  that  Alice  attempted 
to  cheat. 

7  Denial  of  Service 

The  SAS  signature  protocol,  unlike  traditional  signa¬ 
ture  schemes,  involves  multiple  parties  and  commu¬ 
nication.  It  is  therefore  subject  to  Denial  of  Service 
(DoS)  attacks.  Since  we  assume  that  the  communi¬ 
cation  channel  is  reliable  (cf.  Section  4.3),  only  hos¬ 
tile  DoS  attacks  are  of  interest.  Also,  our  channel 
assumption  states  that  all  messages  eventually  get 


through;  thus,  attacks  on  the  communication  media 
are  ruled  out. 

There  are  two  types  of  DoS  attacks:  user  attacks 
and  SEM  attacks.  The  purpose  of  a  user  attack  is 
to  deny  service  to  a  particular  user  whereas  the  pur¬ 
pose  of  a  SEM  attack  is  to  deny  service  to  all  users 
served  by  a  SEM.  User  attacks  can  be  further  divided 
into  request  and  reply  attacks.  Request  attacks  in¬ 
volves  modifying  (or  injecting)  a  user’s  signature  re¬ 
quest  and  a  reply  attack  -  modifying  a  SEM’s  reply. 

7.1  User  Attacks 

Suppose  that  an  adversary  (Eve)  intercepts  the  sig¬ 
nature  request  and  mounts  a  request  attack.  In  this 
case,  SEM  receives  a  request  that  is  perfectly  legiti¬ 
mate  (well-formed)  from  its  point  of  view.  It  proceeds 
to  sign  it  and  send  the  signed  reply  back  to  Alice. 
Clearly,  Alice  discards  the  reply  because  it  contains 
a  signature  for  a  different  message.  If  Eve  prevents 
the  reply  from  reaching  Alice,  she  gains  no  advantage 
since,  as  explained  above,  forging  a  signature  requires 
Eve  to  come  up  with  a  one-time  public  key  which  she 
cannot  do  without  breaking  the  hash  function.  Even 
if  the  reply  does  not  arrive  immediately,  according  to 
our  communication  assumption,  it  eventually  reaches 
Alice  who  promptly  detects  an  attack. 

A  slight  variation  on  the  above  occurs  when  Eve 
has  in  her  possession  the  last  SAS  signature  gener¬ 
ated  by  Alice.  In  this  case,  Eve  can  contact  Alice’s 
SEM  with  a  well-formed  request  and  without  Alice’s 
knowledge,  i.e.,  Alice  is  off-line.  However,  this  attack 
results  in  the  same  outcome  as  the  above.  This  is  be¬ 
cause,  eventually,  Alice  requests  a  new  signature  and 
SEM  replies  with  the  last  (signed)  reply.  Alice,  once 
again,  detects  an  attack. 

We  note  that  these  attacks  can  be  prevented:  one 
way  to  do  so  is  for  Alice  not  to  reveal  her  i- th  signa¬ 
ture  until  ( i  —  l)-st  signature  is  computed.  In  other 
words,  every  other  signature  would  be  used  strictly 
for  this  purpose.  Then,  if  we  suppose  that  Alice-SEM 
communication  is  private,  revealing  SIGi  to  Bob  (or 
Eve)  is  safe  since  a  successful  request  to  Alice’s  SEM 
would  require  knowledge  of  SKi_  i  which  Alice  does 
not  reveal  until  the  next  signature  is  requested.  Yet 
another  solution  is  to  use  a  second,  different  hash 
chain  for  the  sole  purpose  to  authenticate  Alice’s  re¬ 
quests  to  the  SEM. 

All  in  all,  request  attacks,  while  possible,  are  de¬ 
tected  by  the  SAS  signature  protocol  due  to  its  “fail- 
stop”  property:  any  manipulation  of  the  signature 
request  is  detected  by  the  user  who  can  then  invali¬ 
date  its  own  certificate. 
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User  reply  attacks  are  comparatively  less  effective. 
If  Eve  modifies  SEM’s  reply,  short  of  forging  an  RSA 
signature,  Alice  detects  that  the  reply  is  not  what  she 
expected  and  continues  re-transmitting  her  signature 
request. 

7.2  SEM  Attacks 

By  virtue  of  serving  a  multitude  of  regular  users,  a 
SEM  is  a  natural  DoS  attack  target.  This  is  not 
unique  to  SAS.  For  instance,  it  is  easy  to  mount  an 
effective  DoS  attack  against  an  OCSP  [1]  (or  even 
worse,  a  TSP  [16])  server.  It  suffices  for  the  adversary 
to  flood  the  victim  server  with  well-formed  requests, 
i.e. ,  requests  for  which  the  server  is  “authoritative”  in 
OCSP.  Since  the  server  must  digitally  sign  all  replies, 
it  will  slowly  grind  to  a  halt. 

In  SAS,  it  is  appreciably  more  difficult  for  the  ad¬ 
versary  to  launch  this  type  of  an  attack.  The  stateful 
nature  of  the  SEM  requires  each  signature  request  to 
be  well-formed:  it  must  contain  the  expected  value 
of  the  current  one-time  public-key,  i.e.,  the  pre-image 
of  the  previously  used  public-key.  All  other  requests 
are  promptly  discarded. 

Therefore,  in  order  to  force  the  SEM  to  perform 
any  heavy-weight  tasks  (of  which  signing  is  really  the 
only  one),  the  adversary  must  mount  simultaneous 
user  request  attacks  on  as  many  users  as  possible  thus 
hoping  to  flood  the  SEM.  However,  even  if  this  were 
possible,  the  attack  would  quickly  subside  since  the 
SEM  will  only  perform  a  single  signature  operation 
per  user  before  demanding  to  see  a  pre-image  (next 
one-time  public  key).  As  we  already  established,  find¬ 
ing  the  pre-image  of  the  last  signed  one-time  public 
key  is  computationally  infeasible. 

7.3  Loss  of  State 

As  SAS  requires  a  non-trivial  amount  of  state  to  be 
maintained  by  both  users  and  SEMs,  we  need  to  con¬ 
sider  the  potential  disaster  scenarios  that  result  in  a 
loss  of  state. 

Suppose  that  Alice  looses  all  records  of  her  prior 
signatures  along  with  the  signature  counter.  We  fur¬ 
ther  assume  that  she  still  has  possession  of  her  SAS 
certificate  and  the  secret  hash  chain  seed.  Since  these 
two  values  are  fairly  long-term,  it  is  reasonable  for  Al¬ 
ice  to  store  them  in  more  permanent  storage.  Because 
of  the  “amnesia” ,  Alice  will  attempt  to  obtain  the  ini¬ 
tial  signature  from  the  SEM.  Since  SEM  has  retained 
all  relevant  state,  it  will  reply  with  the  last  half¬ 
signature  (including  SEM’s  signature  counter)  gener¬ 
ated  for  Alice’s  SAS  certificate.  Once  she  verifies  the 
reply,  Alice  will  realize  her  loss  of  state  and  resort  to 


off-line  means.  However,  if  a  malicious  SEM  is  aware 
of  Alice’s  loss  of  state,  it  can  use  this  to  its  advantage 
by  forging  with  impunity  Alice’s  signatures. 

If  Alice  looses  her  entire  storage,  including  the  SAS 
certificate,  the  consequences  are  not  particularly  dire. 
The  SEM  will  simply  keep  state  of  Alice’s  “orphan” 
certificate  until  it  eventually  expires. 

Any  loss  of  SEM’s  state  is  much  more  serious.  Most 
importantly,  if  the  SEM  looses  all  state  pertaining  to 
Alice’s  SAS  certificate,  the  SAS  Invariant  property 
can  no  longer  be  guaranteed.  (Consider,  for  example, 
malicious  Alice  re-establishing  state  of  her  SAS  cer¬ 
tificate  on  the  SEM  and  then  obtaining  n  signatures 
with  the  same  hash  chain.) 

7.4  SEM  Compromise 

SEM  compromise  is  clearly  the  greatest  risk  in  SAS. 
The  adversary  who  gains  control  of  a  SEM  can 
un-revoke  or  refuse  to  revoke  SAS  user  certificates. 
Moreover,  it  becomes  possible  to  produce  fraudulent 
user  signatures:  since  state  is  kept  of  all  prior  SAS 
signatures  (corresponding  to  active  SAS  certificates), 
the  adversary  can  sign  on  behalf  of  Alice  for  each 
( SK\ ,  SKlA'1)  pair  found  in  SEM’s  storage. 

Nonetheless,  a  defrauded  SEM  user  can  still  have 
recourse  if  she  faithfully  keeps  state  of  all  prior  SAS 
signatures.  Referring  to  the  SAS  dispute  resolution 
procedure,  when  an  arbitrator  is  presented  with  two 
distinct  and  verifiable  SAS  signatures  for  the  same 
(SKlA,SKlAl)  pair,  he  concludes  that  the  SEM  has 
attempted  to  cheat. 

7.5  Suicide  in  SAS 

In  order  to  provide  rapid  and  effective  response  to 
potential  attacks,  SAS  includes  a  way  for  the  user 
to  “self-revoke”  a  SAS  certificate.  This  is  easily  ob¬ 
tained  by  placing  a  new  value  (X.509  extension)  in 
the  SAS  certificate.  This  value,  referred  to  as  the 
“suicide  hash”,  is  the  hash  of  a  randomly  selected 
secret  quantity  generated  by  Alice  when  composing 
her  certificate  request.  To  self-revoke  the  certificate, 
Alice  simply  communicates  the  corresponding  suicide 
pre-image  to  the  SEM  and  the  CA.  As  a  result,  the 
former  simply  stops  honoring  any  further  signature 
requests  (pertaining  to  Alice’s  certificate)  while  the 
latter  places  a  reference  to  the  said  certificate  on  the 
next  CRL. 

A  similar  technique  has  been  suggested  (with  the 
value  revealed  by  the  CA  instead)  by  Micali  [17]  as 
part  of  a  proposal  for  an  efficient  revocation  scheme. 
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8  Implementation  and  Experi¬ 
ments 

To  better  understand  the  implications  of  using  SAS 
and  to  obtain  valuable  experimental  and  practical 
data,  we  implemented  the  SAS  scheme,  first  as  a 
limping  proof-of-concept  prototype  and,  later,  as  a 
fully  functional  and  publicly  available  package. 

The  implementation,  for  the  most  part,  follows  the 
protocol  as  presented  in  Section  5.  The  SAS  certifi¬ 
cate  issuance  is  done  strictly  off-line:  all  users  obtain 
their  SAS  certificates  from  the  CA  as  described  in 
Section  5.1.  The  newly  issued  certificates  are  either 
transferred  to  SEM  off-line  or  piggybacked  onto  each 
user’s  initial  SAS  signature  request.  We  limit  our  im¬ 
plementation  discussion  owing  to  space  limitations; 
further  details,  including  the  SAS  signature  and  SAS 
certificate  formats  can  be  found  in  Appendix  A. 

8.1  SAS  Application  Example:  Eu- 
dora  Plug-in 

To  demonstrate  the  ease  and  utility  of  the  SAS  sig¬ 
natures,  we  developed  a  plug-in  (on  top  of  the  SAS 
user  library  [18])  for  the  popular  Eudora  [19]  mailer. 

When  composing  email,  the  sender  simply  clicks  on 
the  plug-in  button.  When  ready  to  send,  the  plug¬ 
in  reads  the  user’s  SAS  certificate  and  extracts  the 
SEM’s  address.  It  then  communicates  with  the  SEM 
to  obtain  a  SAS  signature  on  the  email  message.  The 
resulting  signed  email  is  verified  automatically  by  the 
Eudora  plug-in  on  the  receiver’s  side.  Even  if  the  re¬ 
ceiver  does  not  use  Eudora,  the  SAS-signed  email  can 
be  verified  by  any  S/MIME  capable  email  client  such 
as  Netscape  Messenger  or  Microsoft  Outlook.  The 
verification,  however,  requires  the  receiver  (verifier) 
to  install  a  stand-alone  SAS  email  verifier  program. 
This  program  is  registered  as  the  viewer  for  the  new 
MIME  type  (“x.SAS-signature’  ’)• 

Figure  3  shows  a  screen  snapshot  of  the  Eudora 
message  composition  window  when  the  user  is  ready 
to  send  a  signed  email.  It  is  essentially  the  same  as 
the  normal  Eudora  screen  except  for  the  small  SAS 
button  at  the  toolbar  along  the  top  of  the  window. 
Figure  4  depicts  a  screen  snapshot  of  the  Eudora 
mailer  showing  a  SAS-signed  email  message  being  re¬ 
ceived.  The  user  is  presented  with  a  signature  icon  on 
the  message  screen;  clicking  on  it  causes  the  mailer  to 
invoke  the  plug-in’s  verification  function  the  output 
of  which  is  displayed  in  the  Figure  5. 

To  conserve  space  we  omit  the  depiction  of  a  user 
trying  to  sign  email  with  a  revoked  certificate.  In  this 
case,  the  plug-in  displays  an  error  message  informing 


Figure  3:  Snapshot  of  signer  plug-in 


Figure  4:  Verifier  plug-in:  signed  email 


the  user  of  his  certificate’s  demise.  Further  details  on 
the  Eudora  plug-in  can  be  found  in  Appendix  A. 

8.2  Experimental  Results 

As  emphasized  in  the  introduction,  one  of  the  main 
goals  of  SAS  is  to  off-load  the  bulk  of  signature  com¬ 
putation  from  the  weak  user  to  the  powerful  SEM.  To 
validate  the  goals  and  experiment  with  the  SAS  im¬ 
plementation,  we  ran  a  number  of  tests  with  various 
hardware  platforms  and  different  RSA  key  sizes. 

All  experiments  were  conducted  over  a  100  Mbit 
Ethernet  LAN  in  a  lab  setting  with  little,  if  any,  ex¬ 
traneous  network  traffic.  All  test  machines  ran  Linux 
version  2.2  with  all  non-essential  services  turned  off. 
The  hardware  platforms  ranged  from  a  measly  233- 
MHz  PI  (Pentium  I)  to  a  respectable  1.2-GHz  PIV 
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Figure  5:  Verifier  plug-in:  verification 


form  is  a  233-MHz  Pentium  I  laptop  which  is  signif¬ 
icantly  faster  than  a  typical  PDA  or  a  cell  phone. 
The  motivation  was  to  show  that,  even  a  relatively 
fast  user  CPU,  the  speedup  from  SAS  is  appreciable. 
Clearly,  a  more  realistic  scenario  would  involve,  for 
example,  a  60-  to  100-MhZ  PDA  as  the  user  platform 
and  a  1.7-  to  2-GhZ  PIV  as  a  SEM. 

As  is  evident  from  Table  8.2,  all  four  user  platforms 
experience  noticeable  speed-up  as  a  result  of  using 
SAS,  as  compared  with  plain  RSA.  It  is  not  surpris¬ 
ing  that  the  two  low-end  clients  (233-MHz  and  500- 
MHz)  obtain  a  factor  4  to  6  speed-up  depending  on 
the  key  size.  It  is  interesting,  however,  that  the  seem¬ 
ingly  most  powerful  client  platform  (1. 2-GHz  PIV) 
also  experiences  a  small  speed-up.  However,  looking 
at  Table  8.2,  it  becomes  clear  that  the  1. 2-GHz  PIV 
is  not  the  fastest  platform  after  all.  The  explanation 
for  this  oddity  rests  with  the  chip  maker. 


(Pentium  IV).  Note  that  we  selected  the  lowest-end 
platform  conservatively:  only  very  high-end  PDAs 
and  palmtops  approach  200-MHz  processor  speed; 
most  are  in  the  sub-lOOMhz  range.  Our  choice  of  the 
SEM  platform  is  similarly  conservative:  a  933-MHz 
PHI.  (At  the  time  of  this  writing,  1.7-GHz  platforms 
are  available  and  affordable.) 


Processor 

Key  length  (bits) 

1024 

2048 

4096 

8192 

PI-233  MHz 

40.3 

252.7 

1741.7 

12,490.0 

PIII-500  MHz 

14.6 

85.6 

562.8 

3,873.3 

PIII-700  MHz 

9.2 

55.7 

377.8 

2,617.5 

PIII-933  MHz 

7.3 

43.9 

294.7 

2,052.0 

PIV- 1.2  GHz 

9.3 

58.7 

401.2 

2,835.0 

Table  1:  Plain  RSA  signature  timings  (ms) 


First,  we  present  in  Table  8.2  plain  RSA  timings 
conducted  with  OpenSSL  on  the  five  hardware  plat¬ 
forms.  Table  8.2  illustrates  the  SAS  timing  measure¬ 
ments  on  the  four  user  platforms  with  the  SEM  dae¬ 
mon  running  on  a  933-MHz  PHI.  All  SAS  timings 
include  network  transmission  time  as  well  as  SEM 
and  user  processing  times.  Finally,  Table  8.2  shows 
the  LAN  round-trip  communication  delay  between 
the  user  and  the  SEM,  for  different  key  sizes.  The 
size  of  the  signature  request  is  determined  by  the  di¬ 
gest  size  of  the  hash  function,  whereas,  SEM’s  replies 
vary  from  roughly  164  bytes  for  1024-bit  RSA  key  to 
around  1,060  bytes  for  an  8K-bit  RSA  key. 

We  purposely  used  fairly  conservative  platforms  for 
both  the  SEM  and  test  users.  The  slowest  user  plat- 


Processor 

Key  length  (bits) 

1024 

2048 

4096 

8192 

PI-233  MHz 

13.3 

52.4 

322.5 

2,143.4 

PIII-500  MHz 

9.1 

46.3 

302.0 

2,070.2 

PIII-700  MHz 

8.5 

45.1 

299.0 

2,059.6 

PIV- 1.2  GHz 

8.5 

45.4 

299.0 

2,061.0 

Table  2:  SAS  signature  timings  (ms) 


To  summarize,  as  Tables  8.2  and  8.2  illustrate,  de¬ 
spite  large  variances  in  the  four  clients’  CPU  speeds, 
the  difference  in  SAS  sign  time  is  very  small.  More¬ 
over,  the  SAS  sign  time  is  only  slightly  higher  than 
the  corresponding  value  for  the  SEM  (PIII-933  MHz) 
in  Table  8.2,  meaning  that  -  communication  delay 
aside  -  a  SAS  client  can  sign  almost  as  fast  as  the 
SEM.  The  reason  is  that,  to  obtain  a  SAS  signature,  a 
user’s  cryptographic  computation  (which  dominates 
the  overall  time)  amounts  to  message  hashing  and 
signature  verification.  Hashing  is  almost  negligible 
as  compared  to  public  key  operations.  RSA  signa¬ 
ture  verification  is  also  quite  cheap  in  comparison  to 
signing  since  we  use  small  public  exponents. 


Processor 

Key  length  (bits) 

1024 

2048 

4096 

8192 

PI-233  MHz 

0.6 

0.7 

1.1 

1.7 

PIII-500  MHz 

0.4 

0.5 

0.8 

1.2 

PIII-700  MHz 

0.1 

0.2 

0.2 

0.3 

PIV-1.2  GHz 

0.4 

0.5 

0.8 

1.2 

Table  3:  Network  round-trip  delay  (ms) 
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9  Benefits  and  Drawbacks 

In  summary,  the  SAS  signature  scheme  offers  several 
important  benefits  as  described  below:  Efficient 
Signatures.  As  follows  from  the  protocol  descrip¬ 
tion  and  our  experimental  results,  the  SAS  signature 
scheme  significantly  speeds  up  signature  computa¬ 
tion  for  slow,  resource-limited  devices.  Even  where 
speed-up  is  not  as  clearly  evident  (e.g.,  with  small 
key  sizes),  SAS  signatures  conserve  CPU  resources 
and,  consequently,  power,  for  battery-operated 
devices. 

Fast  revocation.  To  revoke  a  SAS  certificate,  it 
is  sufficient  for  the  CA  to  communicate  to  the  cor¬ 
rect  SEM.  This  can  be  achieved,  for  example,  with 
CA  simply  issuing  a  new  CRT  and  sending  it  to  the 
SEM.  Thereafter,  the  SEM  will  no  longer  accept  SAS 
signature  requests  for  the  revoked  certificate. 

We  remark  that,  with  traditional  signature  schemes, 
the  user  who  suspects  that  his  key  has  been  com¬ 
promised  can  ask  the  CA  to  revoke  the  certificate 
binding  this  key  to  the  user.  However,  the  adversary 
can  continue  ad  infinitum  to  use  the  compromised 
key  and  the  verification  burden  is  placed  on  all 
potential  verifiers  who  must  have  access  to  the  latest 
CRL.  With  SAS,  once  the  SEM  is  notified  of  a 
certificate’s  revocation,  the  adversary  is  no  longer 
able  to  interact  with  the  SEM  to  obtain  signatures. 
Hence,  potential  compromise  damage  is  severely 
reduced. 

More  secure  signatures.  Since  only  a  SEM 
performs  real  RSA  public  key  operations  (key  gen¬ 
eration,  signature  computation),  it  can  do  so  with 
stronger  RSA  keys  than  would  otherwise  be  used  by 
the  users.  Indeed,  a  small  PDA-like  device  is  much 
less  likely  to  generate  high-quality  (or  sufficiently 
long)  RSA  factors  (p,  q)  and  key-pairs  than  a  much 
more  powerful  and  sophisticated  SEM. 

Signature  Causality.  Total  order  can  be  imposed 
over  all  SAS  signatures  produced  by  a  given  user. 
This  is  a  direct  consequence  of  the  hash  chain 
construction  and  the  SAS  Invariant.  In  other 
words,  total  ordering  can  be  performed  using  the 
monotonically  increasing  signature  counter  included 
in  each  SAS  signature. 

Dispute  Resolution.  Signature  Causality  can 
be  used  to  provide  unambiguous  dispute  resolution 
in  case  of  private  key  compromise.  Recall  that 
the  compromise  of  a  private  key  in  a  traditional 


signature  scheme  results  in  chaos.  In  particular,  all 
prior  signatures  become  worthless  unless  the  use  of 
a  secure  timestamping  service  is  explicitly  mandated 
for  all  signer  and  signatures.  In  SAS,  once  the  time 
of  compromise  is  established,  signatures  can  be  easily 
sorted  into  pre-  and  post-revocation  piles. 

Attack  Detection.  As  discussed  in  Section  7, 
an  adversary  can  succeed  in  obtaining  a  single 
fraudulent  half-signature  (not  a  full  SAS  signature) 
by  substituting  a  message  of  its  own  choosing 
in  the  user’s  signature  request.  This  essentially 
closes  the  door  for  the  adversary  since  it  is  unable 
to  obtain  further  service  (short  of  inverting  the 
hash  function).  The  real  user  will  detect  that 
an  attacks  has  taken  place  the  next  time  when  it 
tries  to  run  the  SAS  signature  protocol  with  its  SEM. 

Limited  Damage.  Even  if  the  entire  SAS  hash 
chain  is  compromised  (i.e.,  an  adversary  obtains 
the  seed  of  the  hash  chain),  the  damage  is  con¬ 
tained  since  the  adversary  can  generate  at  most  n 
signatures.  Furthermore,  a  user  whose  hash  chain 
is  compromised  will  detect  the  compromise  the 
very  next  time  she  attempts  to  contact  the  SEM. 
(This  is  because  the  SEM  will  reply  with  its  last 
half-signature  ostensibly  computed  for  the  requesting 
user.) 

Alas,  the  SAS  scheme  has  some  notable  drawbacks 
as  well: 

•  Each  SEM  is  a  single  point  of  failure  and  a 
performance  bottleneck  for  the  users  it  serves. 

•  As  discussed  in  Section  7,  a  SEM  signs  (with  RSA, 
to  produce  its  half-signature)  a  response  to  every 
well-formed  signature  request.  This  feature  can  be 
exploited  by  an  adversary  in  order  to  mount  a  DoS 
attack.  However,  even  the  best  attack  can  succeed 
in  making  a  SEM  sign  at  most  once  for  each  user  it 
serves.  Of  course,  an  adversary  can  still  flood  any 
SEM  with  malformed  requests  which  can  certainly 
render  a  SEM  unavailable  to  legitimate  users. 

•  Unlike  other  mediated  or  multi-party  signature 
methods  (such  as  mRSA  or  2-party  DSA),  SAS 
signatures  are  not  compatible  with  any  other  basic 
signature  type.  In  other  words,  SAS  signatures  are 
not  transparent  to  verifiers.  Therefore,  all  potential 
verifiers  must  avail  themselves  of  at  least  the  SAS 
verification  method. 

•  It  is  possible,  but  neither  easy  nor  elegant,  for 
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a  user  to  switch  among  different  SEMs  in  SAS. 
One  way  is  to  have  multiple  SAS  certificates;  one 
for  a  distinct  SEM.  Another  way  is  to  use  on-line 
hand-over  of  a  SAS  certificate  among  two  SEMs. 
Neither  solution  is  particularly  attractive  due  to 
the  difficulty  of  replication  of  a  statfule  server.  (In 
mRSA  [4],  for  example,  a  user  can  swich  among 
SEMs  transparently,  where  SEM  is  stateless.  ) 

•  SAS  involves  on-going  state  retention  for  regular 
users  and  SEMs.  This  burden  is  particularly  heavy 
for  SEMs  (users  can  off-load  their  state  periodically) 
since  they  must  keep  complete  signature  histories  for 
all  users  served. 
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Appendix  A:  SAS  Implementa¬ 
tion  Details 

A.l  SAS  Signature  Format 

The  well-known  PKCS#7  [20]  standard  defines  a  gen¬ 
eral  cryptographic  message  syntax  for  digital  signa¬ 
tures.  In  it,  Signerlnfor  includes  an  optional  set 
of  signed  attributes  as  well  as  an  optional  set  of  un¬ 
signed  attributes.  This  flexibility  allows  us  to  easily 
extend  the  PKCS#7  signature  syntax  to  accommo¬ 
date  SAS  signatures.  This  is  because  a  SAS  signature 
can  be  viewed  as  a  regular  public  key  signature  with 
an  appended  extra  value,  i.e.,  the  hash  pre-image. 

The  format  changes  are  only  a  few  new 
requirements  for  authenticatedAttributes  and 


unauthenticatedAttributes  of  the  Signerlnfor 
field.  In  a  SAS  signature,  Signerlnfor  is  the  same 
as  in  plain  PKCS#7,  except: 

•  authenticatedAttributes: 

this  field  is  not  OPTIONAL,  but  MANDA¬ 
TORY.  It  must  contain,  at  a  minimum,  two  more 
attributes  aside  from  those  set  in  PKCS#7: 

—  SAS_issuer_sn:  Issuer  AndSerialNumber 
specifies  the  SAS  client’s  certificate  by  is¬ 
suer  name  and  issuer-specific  serial  number 

—  SAS  signed  token  index:  INTEGER 

specifies  the  SAS  client  signed  one-time  sig¬ 
nature  index  (counter) 

—  SAS_signed_token_value:  OCTET  STRING 
-  specifies  the  SAS  client  signed  one-time 
public  key 

Note  that  PKCS#7  requires 

issuerAndSerialNumber  in  Signerlnfo  to 
identify  signer’s  key.  In  SAS,  this  corresponds 
to  SEM’s  key.  Therefore,  we  require  another 
field  SAS_issuer_sn  to  identify  the  user’s  SAS 
certificate  containing  the  SAS  root  key.  The 
signed  token  is  not  placed  into  Contentlnfo  so 
that  the  message  digest  handling  is  the  same 
as  with  any  other  public  key  signature  type. 
Moreover,  the  token  can  be  extracted  from 
PKCS#7  independently,  if  necessary. 

•  unauthenticatedAttributes: 

this  field  is  not  OPTIONAL,  but  MANDA¬ 
TORY.  It  must  contain: 

—  SAS_preimage_token_value:  OCTET 

STRING  -  specifies  the  SAS  user’s  one¬ 
time  hash  pre-image  of  the  signed  token 
specified  in  SAS_signedtoken_value.  This 
attribute  is  unsigned.  It  is  inserted  by 
the  user  when  the  SEM’s  half-signature  is 
received  and  verified. 

Because  of  format  compatibility,  a  SAS  signature  can 
be  shipped  as  a  normal  PKCS#7  signature.  How¬ 
ever,  the  verification  method  is  obviously  different. 
The  normal  PKCS^7  verification  routines  can  only 
verify  the  SEM  half-signature  (i.e.,  RSA  public  key 
signature). 

The  extra  step  in  (light)  verification  of 
a  SAS  signature  is  the  comparison  of  the 
hash  of  SAS_preimage_token_value  and  the 
SAS_signed_token_value  assuming  light  verification 
is  used.  Otherwise,  as  described  above,  the  verifier 
checks  the  validity  of  SAS_signed_token_value  and 
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SAS_signed_token_index  by  computing  the  iterative 
hash  and  comparing  the  result  with  the  SAS  root 
key  in  the  signer’s  SAS  certificate. 

The  fact  that  two  parties  participate  in  signing 
result  in  a  semantic  issue  when  SAS  signatures  are 
used  in  conjunction  with  S/MIME.  Most  S/MIME 
applications  enforce  a  policy  requiring  the  sender  of 
the  message  (as  shown  in  the  RFC822  From:  field) 
to  match  the  e-mail  address  in  the  signer  certificate. 
Unfortunately,  in  SAS,  the  sender  is  the  holder  of  the 
SAS  certificate,  e.g.,  alice@wonderland.com.  Whereas, 
the  “signer”  is  the  SEM,  e.g.,  sem@wonderland.com. 
Therefore,  a  SAS  verifier  should  be  aware  of  the  pres¬ 
ence  of  the  unsigned  attribute  and  use  the  proper 
email  address  in  comparison. 

A. 2  SAS  Certificate 

To  support  SAS  attributes,  we  extended  X509v3  han¬ 
dling  [21]  in  the  popular  Openssl  library  [22].  In  ad¬ 
dition  to  the  usual  X509v3  fields,  a  SAS  certificate 
also  certifies  the  following: 

•  SASHashType:  DigestAlgorithmldentif ier 

identifies  the  hash  algorithm  used  in  generating 
the  hash  chain; 

•  SASPublicKey Identifier:  OCTET  STRING 

SAS  root  key  in  the  hash-chain. 

•  SASPublicKeyPara:  INTEGER  length  of  the 
hash-chain. 

•  SASServerName:  STRING  SEM’s  host  name. 
This  field  indicates  the  location  of  SEM  and  has 
no  security  meaning. 

•  SASSerialNumber:  INTEGER  SEM’s  certificate 
serial  number.  (Here  it  is  assumed  that  the  SEM 
and  the  user  share  the  same  CA) .  Uniquely  iden¬ 
tifies  SEM’s  certificate  and  the  corresponding 
public  key. 

A. 3  Eudora  Plug-in  Details 

We  implemented  the  SAS  plug-in  as  two  email  trans¬ 
lators  defined  in  Eudora’s  plug-in  API  [19].  Specif¬ 
ically,  SAS  signing  is  a  (^^-Transmission  translator 
and  SAS  verification  is  an  On-Display  translator. 

SAS  signing  translator  is  invoked  when  Eudora 
is  ready  to  send  email  and  is  fed  with  the  entire 
email  message,  including  its  MIME  header.  When 
SAS  signature  protocol  terminates,  the  whole  SAS 
signature  in  PKCS#7  format  is  appended  to  the 
email  body  as  an  attachment  with  the  MIME  sub- 
type  ‘ ‘x.SAS-signature’ ’. 


SAS  verification  translator  is  called  when  Eudora 
is  about  to  display  a  SAS-signed  email.  As  in  tradi¬ 
tional  signature  verification,  a  certificate  chain  must 
be  at  hand.  Our  plug-in  allows  users  to  specify  the 
root  CA  certificate,  assuming,  of  course,  that  the 
SEM  and  the  SAS  client  share  the  same  certificate 
issuer.  It  is  easy  to  build  a  chain  by  extracting  SEM 
and  client’s  certificate  from  the  PKCS#7  signature. 
In  this  implementation,  we  chose  not  to  adopt  opaque 
signing.  If  the  signature  is  invalid,  an  error  message 
window  is  popped  up  while  the  original  email  body 
is  still  displayed. 

Since  SAS  signature  verification  is  different  from 
normal  S/MIME,  non-Eudora  applications,  like 
Netscape  or  Outlook,  cannot  verify  it  without  a  spe¬ 
cial  verification  program.  We  provide  such  a  stand¬ 
alone 

Appendix  B:  Related  Work  on 
Certificate  Revocation 

•  CRLs  and  A-CRLs:  Certificate  Revocation  Lists 
are  the  most  common  way  to  handle  certificate  revo¬ 
cation.  The  Validation  Authority  (VA)  periodically 
posts  a  signed  list  of  all  revoked  certificates.  These 
lists  are  placed  on  designated  servers  called  CRL  dis¬ 
tribution  points.  Since  these  lists  can  get  quite  long, 
a  VA  may  alternatively  post  a  signed  A-CRL  which 
only  contains  the  list  of  revoked  certificates  since  the 
last  CRL  was  issued.  When  verifying  a  signature  on 
a  message,  the  verifier  checks  that,  at  the  time  that 
the  signature  was  issued,  the  signer’s  certificate  was 
not  on  the  CRL. 

•  OCSP:  The  Online  Certificate  Status  Protocol 
(OCSP)  [1]  improves  on  CRLs  by  avoiding  the  trans¬ 
mission  of  long  CRLs  to  every  user  and  by  providing 
more  timely  revocation  information.  The  VA  sends 
back  a  signed  response  indicating  whether  the  spec¬ 
ified  certificate  is  currently  revoked.  When  verifying 
a  signature,  the  verifier  sends  an  OCSP  (certificate 
status  request)  query  to  the  VA  to  check  if  the  en¬ 
closed  certificate  is  currently  valid.  The  VA  answers 
with  a  signed  response  indicating  the  certificate’s  re¬ 
vocation  status.  Note  that  OCSP  prevents  one  from 
implementing  stronger  semantics:  it  is  impossible  to 
ask  an  OCSP  VA  whether  a  certificate  was  valid  at 
some  time  in  the  past. 

•  Certificate  Revocation  Trees:  Kocher  [23]  sug¬ 
gested  an  improvement  over  OCSP.  Since  the  VA  is 
a  global  service,  it  must  be  sufficiently  replicated 
to  handle  the  load  of  all  validation  queries.  This 
means  the  VA’s  signing  key  must  be  replicated  across 
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many  servers  which  is  either  insecure  or  expensive 
(VA  servers  typically  use  tamper-resistance  to  pro¬ 
tect  the  VA’s  signing  key).  Kocher’s  idea  is  to  have 
a  single  highly  secure  VA  periodically  post  a  signed 
CRL-like  data  structure  to  many  insecure  VA  servers. 
Users  then  query  these  insecure  VA  servers.  The  data 
structure  (CRT)  proposed  by  Kocher  is  a  hash  tree 
where  the  leaves  are  the  currently  revoked  certificates 
sorted  by  serial  number  The  root  of  the  hash  tree  is 
signed  by  the  VA. 

A  user  wishing  to  validate  a  certificate  issues  a 
query  to  the  closest  VA  server.  Any  insecure  VA 
can  produce  a  convincing  proof  that  the  certificate 
is  (or  is  not)  on  the  CRT.  If  n  certificates  are  cur¬ 
rently  revoked,  the  length  of  the  proof  is  0(log?i).  In 
contrast,  the  length  of  the  validity  proof  in  OCSP  is 
0(1). 

•  Skip-lists  and  2-3  trees:  One  problem  with 
CRTs  is  that,  every  time  a  certificate  is  revoked,  the 
entire  CRT  must  be  recomputed  and  distributed  in  its 
entirety  to  the  various  VA  servers.  A  data  structure 
allowing  for  dynamic  updates  would  solve  this  prob¬ 
lem  since  the  secure  VA  would  only  need  to  send  small 
updates  to  the  data  structure  along  with  a  signature 
on  the  new  root  of  the  structure.  Both  2-3  trees  pro¬ 
posed  by  Naor  and  Nissim  [24]  and  skip-lists  proposed 
by  Goodrich  [25]  are  natural  data  structures  for  this 
purpose.  Additional  data  structures  were  proposed 
in  [26].  When  a  total  of  n  certificates  are  already  re¬ 
voked  and  k  new  certificates  must  be  revoked  during 
the  current  time  period,  the  size  of  the  update  mes¬ 
sage  to  the  VA  servers  is  0(k\ogn)  (as  opposed  to 
0(n)  with  CRT’s).  The  proof  of  certificate’s  validity 
is  O(logn),  same  as  with  CRTs. 
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Abstract 

We  present  a  new  approach  to  fast  certificate  re¬ 
vocation  centered  around  the  concept  of  an  on-line 
semi-trusted  mediator  (SEM).  The  use  of  a  SEM  in 
conjunction  with  a  simple  threshold  variant  of  the 
RSA  cryptosystem  (mediated  RSA)  offers  a  num¬ 
ber  of  practical  advantages  over  current  revocation 
techniques.  Our  approach  simplifies  validation  of 
digital  signatures  and  enables  certificate  revocation 
within  legacy  systems.  It  also  provides  immediate 
revocation  of  all  security  capabilities.  This  paper 
discusses  both  the  architecture  and  implementation 
of  our  approach  as  well  as  performance  and  compat¬ 
ibility  with  the  existing  infrastructure.  Our  results 
show  that  threshold  cryptography  is  practical  for 
certificate  revocation. 


1  Introduction 

We  begin  this  paper  with  an  example  to  illustrate 
the  premise  for  this  work.  Consider  an  organization 
-  industrial,  government  or  military  -  where  all  em¬ 
ployees  (referred  to  as  users)  have  certain  authori¬ 
ties  and  authorizations.  We  assume  that  a  modern 
Public  Key  Infrastructure  (PKI)  is  available  and  all 
users  have  digital  signature,  as  well  as  encryption, 
capabilities.  In  the  course  of  performing  routine  ev¬ 
eryday  tasks  users  take  advantage  of  secure  applica¬ 
tions  such  as  email,  file  transfer,  remote  log-in  and 
web  browsing. 

Now  suppose  that  a  trusted  user  (Alice)  does  some¬ 
thing  that  warrants  immediate  revocation  of  her  se- 
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curity  privileges.  For  example,  Alice  might  be  fired, 
or  she  may  suspect  that  her  private  key  has  been 
compromised.  Ideally,  immediately  following  revo¬ 
cation,  Alice  should  be  unable  to  perform  any  se¬ 
curity  operations  and  use  any  secure  applications. 
Specifically,  this  means: 

-  Alice  cannot  read  secure  (private)  email.  This 
includes  encrypted  email  that  is  already  resid¬ 
ing  on  Alice’s  email  server.  Although  encrypted 
email  may  be  basically  delivered  (to  Alice’s  email 
server),  she  cannot  decrypt  it. 

-  Alice  cannot  generate  valid  digital  signatures  on 

any  further  messages.  (However,  signatures  gen¬ 
erated  by  Alice  prior  to  revocation  may  need  to 
remain  valid.) 

-  Alice  cannot  authenticate  herself  to  corporate 
servers. 

In  Section  7,  we  discuss  current  revocation  tech¬ 
niques  and  demonstrate  that  the  above  require¬ 
ments  are  impossible  to  satisfy  with  these  tech¬ 
niques.  Most  importantly,  current  techniques  do  not 
provide  immediate  revocation. 

1.1  The  SEM  architecture. 

Our  approach  to  immediate  revocation  of  security 
capabilities  is  called  the  SEM  architecture.  It  is  easy 
to  use  and  its  presence  is  transparent  to  peer  users 
(those  that  encrypt  messages  and  verify  signatures). 
The  basic  idea  is  as  follows: 

We  introduce  a  new  entity,  referred  to  as  a  SEM 
(SEcurity  Mediator).  A  SEM  is  an  online  semi- 
trusted  server.  To  sign  or  decrypt  a  message,  Al¬ 
ice  must  first  obtain  a  message-specific  token  from 
the  SEM.  Without  this  token  Alice  cannot  use  her 
private  key A  To  revoke  Alice's  ability  to  sign  or  de- 

1The  exact  description  of  the  token  is  in  Section  2. 
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crypt,  the  security  administrator  instructs  the  SEM 
to  stop  issuing  tokens  for  Alice ’s  public  key.  At  that 
instant,  Alice's  signature  and/or  decryption  capa¬ 
bilities  are  revoked.  For  scalability  reasons,  a  SEM 
serves  many  users. 

We  emphasize  that  the  SEM  architecture  is  trans¬ 
parent  to  peer  users:  with  SEM’s  help,  Alice  can 
generate  a  standard  RSA  signature,  and  decrypt 
standard  messages  encrypted  with  her  RSA  public 
key.  Without  SEM’s  help,  she  cannot  perform  ei¬ 
ther  of  these  operations.  The  SEM  architecture  is 
implemented  using  threshold  RSA  [3]  as  described 
in  section  2. 

To  experiment  with  this  architecture  we  imple¬ 
mented  it  using  OpenSSL  [12].  SEM  is  implemented 
as  a  daemon  process  running  on  a  server.  We  de¬ 
scribe  our  implementation,  the  protocols  used  to 
communicate  with  the  SEM,  and  give  performance 
results  in  Sections  5  and  6. 

We  also  built  a  plug-in  for  the  Eudora  client  en¬ 
abling  users  to  send  signed  email.  All  signatures  are 
generated  with  SEM’s  help  (see  [15]).  Consequently, 
signing  capabilities  can  be  easily  revoked. 

1.2  Decryption  and  signing  in  the  SEM 
architecture 


We  now  describe  in  more  detail  how  decryption  and 
signing  is  done  in  the  SEM  architecture: 

-  Decryption:  suppose  Alice  wishes  to  decrypt  an 
email  message  using  her  private  key.  Recall  that  en¬ 
crypted  email  is  composed  of  two  parts:  (1)  a  short 
header  containing  a  message-key  encrypted  using 
Alice’s  public  key,  and  (2)  the  body  contains  the 
email  message  encrypted  using  the  message-key.  To 
decrypt,  Alice  first,  sends  the  short  header  to  her 
SEM.  SEM  responds  with  a  short  token.  This  to¬ 
ken  enables  Alice  to  read  her  email.  However,  it 
contains  no  useful  information  to  anyone  but  Alice. 
Hencij;  communication  with  the  SEM  does  not  have 
to  be  protected  or  authenticated.  We  note  that  in¬ 
teraction  with  the  SEM  is  fully  managed  by  Alice’s 
email  reader  and  does  not  require  any  intervention 
on  Alice’s  part..  This  interaction  does  not.  use  Al¬ 
ice’s  private  key.  If  Alice  wants  to  read  her  email 
offline,  the  interaction  with  the  SEM  takes  places  at. 
the  time  Alice’s  email  client,  downloads  Alice’s  email 
from  the  email  server. 


-  Signatures:  suppose  Alice  wishes  t.o  sign  a.  mes¬ 
sage  using  her  private  key.  She  sends  a.  hash  of  the 
message  to  the  SEM  which,  in  turn,  responds  with 
a.  short,  token  enabling  Alice  to  generate  f.he  signa¬ 
ture.  As  with  decryption,  this  token  contains  no 
useful  information  to  anyone  but.  Alice;  therefore, 
the  interaction  with  the  SEM  is  not.  encrypted  or 
authenticated. 

Note  that,  all  interaction  with  the  SEM  involves  very 
short,  messages. 

1.3  Other  benefits  of  using  a  SEM 

Our  initial  motivation  for  introducing  a.  SEM  is  to 
enable  immediate  revocation  of  Alice’s  key.  We 
point,  out.  that,  the  SEM  architecture  provides  two 
additional  benefits  over  standard  revocation  tech¬ 
niques:  (1)  simplified  signature  validation,  and  (2) 
enabling  revocation  in  legacy  systems.  These  bene¬ 
fits  apply  when  the  following  semantics  for  validat¬ 
ing  digital  signatures  are  used: 

Binding  signature  semantics:  a.  digital  signature 
is  considered  valid  if  the  certificate  associated  with 
the  signature  was  valid  at.  the  time  the  signature 
was  issued. 

A  consequence  of  binding  signature  semantics  is 
that,  all  signatures  issued  prior  to  certificate  revo¬ 
cation  are  valid.  Binding  semantics  are  natural  in 
business  contracts.  For  example,  suppose  Alice  and 
Bob  enter  into  a.  contract..  They  both  sign  the  con¬ 
tract.  at.  time  T.  Bob  begins  to  fulfill  the  contract 
and  incurs  certain  costs  in  the  process.  Now,  sup¬ 
pose  at.  time  T’  >  T ,  Alice  revokes  her  own  certifi¬ 
cate.  Is  the  contract,  valid  at.  time  T'?  Using  binding 
semantics,  Alice  is  still  bound  to  the  contract,  since 
it.  was  signed  at.  time  T  when  her  certificate  was  still 
valid.  In  other  words,  Alice  cannot,  nullify  the  con¬ 
tract.  by  causing  her  own  certificate  to  be  revoked. 

(We  note  that,  binding  semantics  are  inappropriate 
in  some  scenarios.  For  example,  if  a.  certificate  is 
obtained  from  a.  CA  under  false  pretense,  e.g.,  Alice 
masquerading  as  Bob,  the  CA  should  be  allowed  to 
declare  at.  any  time  that,  all  signatures  ever  issued 
under  that,  certificate  are  invalid.) 

Implementing  binding  signature  semantics  with  ex¬ 
isting  revocation  techniques  is  complicated,  as  dis¬ 
cussed  in  Section  7.  Whenever  Bob  verifies  a.  signa- 
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t.ure  generated  by  Alice,  Bob  must  also  verify  that 
Alice’s  certificate  was  valid  at  the  time  the  signature 
was  issued.  In  fact,  every  verifier  of  Alice’s  signa¬ 
ture  must  perform  this  certificate  validation  step. 
However,  unless  a  trusted  timestamping  service  is 
involved  in  generating  all  of  Alice’s  signatures,  Bob 
cannot  trust  the  timestamp  provided  by  Alice  in  her 
signatures. 

Implementing  binding  semantics  with  the  SEM  ar¬ 
chitecture  is  trivial.  To  validate  Alice’s  signature,  a 
verifier  need  only  verify  the  signature  itself.  There 
is  no  need  to  check  the  status  of  Alice’s  certificate.2 
Indeed,  once  Alice’s  certificate  is  revoked  she  can 
no  longer  generate  valid  signatures.  Therefore,  the 
mere  existence  of  the  signature  implies  that  Alices ’s 
certificate  was  valid  at  the  time  the  signature  was 
issued. 

The  above  discussion  brings  out  two  additional  ben¬ 
efits  of  a  SEM  over  existing  revocation  techniques, 
assuming  binding  semantics  are  sufficient. 

-  Simplified  signature  validation.  Verifiers  need  not 
validate  the  signer’s  certificate.  The  existence  of  a 
(verifiable)  signature  is,  in  itself,  a  proof  of  signa¬ 
ture’s  validity. 

-  Enabling  revocation  in  legacy  systems.  Consider 
legacy  systems  doing  signature  verification.  Often, 
such  systems  have  no  certificate  validation  capa¬ 
bilities.  For  example,  old  browsers  (e.g.,  Netscape 
3.0)  verify  server  certificates  without  any  means  for 
checking  certificate  revocation  status.  In  SEM  ar¬ 
chitecture,  certificate  revocation  is  provided  with¬ 
out  any  change  to  the  verification  process  in  these 
legacy  systems.  (The  only  aspect  that  needs  chang¬ 
ing  is  the  signature  generation  process.  However, 
we  note  that,  often,  only  a  few  entities  generate  sig¬ 
natures,  e.g.,  CAs  and  servers.) 


2  Mediated  RSA 


We  now  describe  in  detail  how  the  SEM  interacts 
with  users  to  generate  tokens.  The  proposed  SEM 
architecture  is  based  on  a  variant  of  RSA  which 
we  call  Mediated  RSA  (mRSA).  The  main  idea  in 

2  We  are  assuming  here  that  revocation  of  Alice’s  key  is 
equavalent  to  revocation  of  Alice’s  certificate.  In  general, 
however,  Alice’s  certificate  may  encode  many  rights,  not  just 
the  right  to  use  her  key(s).  It  is  then  possible  to  revoke  only 
some  of  these  rights  while  not  revoking  the  entire  certificate. 


mRSA  is  to  split  each  RSA  private  key  into  two 
parts  using  threshold  RSA  [3].  One  part  is  given  to 
a  user  while  the  other  is  given  to  a  SEM.  If  the  user 
and  the  SEM  cooperate,  they  employ  their  respec¬ 
tive  half-keys  in  a  way  that  is  functionally  equivalent 
to  (and  indistinguishable  from)  standard  RSA.  The 
fact,  that  the  private  key  is  not  held  in  its  entirety  by 
any  one  party  is  transparent  to  the  outside  world, 
i.e. ,  to  the  those  who  use  the  corresponding  public 
key.  Also,  knowledge  of  a  half- key  cannot  be  used 
to  derive  the  entire  private  key.  Therefore,  neither 
the  user  nor  the  SEM  can  decrypt  or  sign  a  mes¬ 
sage  without  mutual  consent.  (A  single  SEM  serves 
a  multitude  of  users.) 

2.1  mRSA  in  detail 

Public  Key.  As  in  RSA,  each  user  (Ui)  has  a  pub¬ 
lic  key  EKi  =  ( n8 ,  e8)  where  the  modulus  n8  is  prod¬ 
uct  of  two  large  primes  pi  and  g8  and  e8  is  an  integer 
relatively  prime  to  <^>(n8). 

Secret  Key.  As  in  RSA,  there  exists  a  corre¬ 
sponding  secret  key  DKi  =  (n8,  d8)  where  d8  *e8  =  1 
(mod  <f>(ni)).  However,  as  mentioned  above,  no  one 
has  possession  of  d8.  Instead,  d8  is  effectively  split 
into  two  parts  d)1  and  dfem  which  are  held  by  the 
user  Ui  and  a  SEM,  respectively.  The  relationship 
among  them  is: 

di  =  d‘em  +  d)1  mod  <j>(n) 

mRSA  Key  Setup.  Recall  that,  in  RSA, 
each  user  generates  its  own  modulus  n8  and 
a  public/secret.  key-pair.  In  mRSA,  a  trusted 
party  (most  likely,  a  CA)  takes  care  of  all  key 
setup.  In  particular,  it  generates  a  distinct  set: 
{pi,  qi,  e8,  and  d8,d*em}  for  each  user.  The  first, 
four  are  generated  in  the  same  manner  as  in  stan¬ 
dard  RSA.  The  fifth  value,  dfem ,  is  a.  random  inte¬ 
ger  in  the  interval  [l,n8].  The  last,  value  is  set.  as: 
d)‘  =  di  -  dfem. 

After  CA  computes  the  above  values,  dfem  is  se¬ 
curely  communicated  to  a.  SEM  and  d)1  -  to  the  user 
Ui .  The  details  of  this  step  are  elaborated  in  Sec¬ 
tion  5. 


mRSA  Signatures.  A  user  generates  a.  signature 
on  a.  message  m  as  follows:;: 
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1 .  The  user  Ui  first,  sends  a  hash  of  the  message  ??? 
to  the  appropriate  SEM. 

-  SEM  checks  that  Ui  is  not  revoked  and,  if 
so,  computes  a  partial  signature  PSsem  = 
md’  (  mod  ??;)  and  replies  with  it  to  the  user. 
This  PSSem  is  the  token  enabling  signature 
generation. 

-  concurrently,  Ui  computes  PSU  =  md<  (mod 

m ) 

2.  Ui  receives  PSsem  and  computes  ???'  =  ( PSsem  * 
PSu)e<  (mod??;).  If  ???'  =  ???,  the  signature  is  set 
to:  (PSsem  *  PSU)  =  mdi  (mod?i;). 

Note  that  in  Step  2  the  user  Ui  validates  the  re¬ 
sponse  from  the  SEM.  Signature  verification  is  iden¬ 
tical  to  that  in  standard  RSA. 


mRSA  Encryption.  The  encryption  process  is 
identical  to  that,  in  standard  RSA.  (In  other  words, 
ciphertext,  is  computed  as  c  =  ???e'  (mod??;)  where 
???  is  an  appropriately  padded  plaintext.,  e.g.,  using 
OAEP . )  Decryption,  on  the  other  hand,  is  very  sim¬ 
ilar  to  signature  generation  above. 

1.  upon  obtaining  an  encrypted  message  c,  user  Ui 
sends  it.  to  the  appropriate  SEM. 

-  SEM  checks  that  Ui  is  not.  revoked  and,  if 
so,  computes  a.  partial  cleartext.  PCsem  = 
cd<  (mod??;)  and  replies  to  the  user. 

-  concurrently,  Ui  computes  PCU  =  cd<  (mod 

m ) . 

2.  Ui  receives  PCsem  and  computes  c'  =  ( PCsem  * 
PCuY'  (mod??;).  If  c1  =  c,  the  cleartext,  mes¬ 
sage  is:  (PCsem  *  PCU)  =  CdC 

2.2  Notable  Features 


As  mentioned  earlier,  mRSA  is  only  a.  slight,  mod¬ 
ification  of  the  RSA  cryptosystem.  However,  at  a. 
higher,  more  systems  level,  mRSA  affords  some  in¬ 
teresting  features. 


CA-based  Key  Generation.  Recall  that,  in 
RSA,  a.  priva.t. e/public  key-pair  is  typically  gener¬ 
ated  by  its  intended  owner.  In  mRSA  the  key-pair  is 
typically  generated  by  a.  CA,  implying  that,  the  CA 
knows  the  private  keys  belonging  to  all  users.  In  the 
global  Internet  this  is  clearly  undesirable.  However, 
in  a.  medium-sized  organization  this  “feature”  pro¬ 


vides  key  escrow.  For  example,  if  Alice  is  fired,  the 
organization  can  still  access  her  work-related  files 
by  obtaining  her  private  key  from  the  CA. 

If  key  escrow  is  undesirable,  it.  is  easy  to  extend  the 
system  in  a.  way  that  no  entity  ever  knows  Alice’s 
private  key  (not.  even  Alice  or  the  CA).  To  do  so,  we 
can  use  a  technique  due  to  Boneh  and  Franklin  [2] 
to  generate  an  RSA  key-pair  so  that  the  private  key 
is  shared  by  a.  number  of  parties  since  its  creation 
(see  also  [4]).  This  technique  has  been  implemented 
in  [8] .  It  can  be  used  to  generate  a.  shared  RSA  key 
between  Alice  and  the  SEM  so  that  no  one  knows 
the  full  private  key.  Our  initial  implementation  does 
not.  use  this  method.  Instead,  the  CA  does  the  full 
key  setup. 


Immediate  Revocation.  The  notoriously  dif¬ 
ficult.  revocation  problem  is  greatly  simplified  in 
mRSA.  In  order  to  revoke  a.  user’s  public  key,  it.  suf¬ 
fices  to  notify  that  user’s  SEM.  Each  SEM  merely 
maintains  a.  list,  of  revoked  users  which  is  consulted 
upon  every  service  request..  Our  implementation 
uses  standard  X.509  Certificate  Revocation  Lists 
(CRT’s)  for  this  purpose. 


Transparency.  mRSA  is  completely  transparent, 
to  those  who  encrypt,  data,  for  mRSA  users  and 
those  who  verify  signatures  produced  by  mRSA 
users.  To  them,  mRSA  appears  indistinguishable 
from  standard  RSA.  Furthermore,  mRSA  certifi¬ 
cates  are  identical  to  standard  RSA  certificates. 


Coexistence.  mRSA’s  built-in  revocation  ap¬ 
proach  can  co-exist,  with  the  traditional,  explicit, 
revocation  approaches.  For  example,  a.  CRL-  or  a. 
CRT-based  scheme  can  be  used  in  conjunction  with 
mRSA  in  order  to  accommodate  existing  implemen¬ 
tations  that  require  verifiers  (and  encrypt.ors)  to 
perform  certificate  revocation  checks. 


CA  Communication.  CA  remains  an  off-line  en¬ 
tity.  mRSA  certificates,  along  with  private  half- keys 
are  distributed  to  the  user  and  SEM-s  in  an  off¬ 
line  manner.  This  follows  the  common  certificate 
issuance  and  distribution  paradigm.  In  fact.,  in  our 
implementation  (Section  5)  there  is  no  need  for  t.hq 
CA  and  the  SEM  to  ever  communicate  directly. 
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No  Authentication.  mRSA  does  not  require  any 
explicit  authentication  between  a  SEM  and  a  user. 
Instead,  a  user  implicitly  authenticates  a  SEM  by 
verifying  its  own  signature  (or  encryption)  as  de¬ 
scribed  in  Section  2.1.  In  fact,  signature  and  en¬ 
cryption  verification  steps  assure  the  user  of  the  in¬ 
tegrity  of  the  communication  with  the  SEM. 


3  Architecture 


The  overall  architecture  is  made  up  of  three  compo¬ 
nents:  CA,  SEM,  and  user. 

A  single  CA  governs  a  (small)  number  of  SEMs. 
Each  SEM,  in  turn,  serves  many  users.  The  assign¬ 
ment  of  users  to  SEM  s  is  assumed  to  be  handled 
off-line  by  a  security  administrator.  A  user  may  be 
served  by  multiple  SEM’s. 

Our  CA  component  is  a  simple  add-on  to  the  exist¬ 
ing  CA  and  is  thus  considered  an  off-line  entity.  For 
each  user,  the  CA  component  takes  care  of  generat¬ 
ing  an  RSA  public  key,  a  corresponding  RSA  public 
key  certificate  and  a  pair  of  half- keys  (one  for  the 
user  and  one  for  the  SEM)  which,  when  combined, 
form  the  RSA  private  key.  The  respective  half-keys 
are  then  delivered,  out-of-band,  to  the  interested 
parties. 

The  user  component  consists  of  the  client  library 
that  provides  the  mRSA  sign  and  mRSA  decrypt 
operations.  (As  mentioned  earlier,  the  verify  and 
encrypt  operations  are  identical  to  standard  RSA.) 
It  also  handles  the  installation  of  the  user’s  creden¬ 
tials  at  the  local  host. 

The  SEM  component  is  the  critical  part  of  the  ar¬ 
chitecture.  Since  a  single  SEM  serves  many  users, 
performance,  fault-tolerance  and  physical  security 
are  of  paramount  concern.  The  SEM  is  basically  a 
daemon  process  that  processes  requests  from  its  con¬ 
stituent  users.  For  each  request,  SEM  consults  its 
revocation  list  and  refuses  to  help  sign  (or  decrypt) 
for  any  revoked  users.  A  SEM  can  be  configured  to 
operate  in  a  stateful  or  stateless  model.  The  former 
involves  storing  per  user  state  (half-key  and  certifi¬ 
cate)  while,  in  the  latter,  no  per  user  state  is  kept, 
however,  some  extra  processing  is  incurred  for  each 
user  request.  The  tradeoff  is  fairly  clear:  per  user 
state  and  fast  request  handling  versus  no  state  and 
somewhat  slower  request  handling. 


We  now  describe  the  SEM  architecture  in  more  de¬ 
tail.  A  user’s  request  is  initially  handled  by  the  SEM 
controller  win  re.  t  In  packet  format  is  checked.  Next, 
the  request  is  passed  on  to  the  client  manager  which 
performs  a  revocation  check.  If  the  requesting  user 
is  not  revoked,  this  request  is  handled  depending  on 
the  SEM  state  model.  If  the  SEM  is  stateless,  it 
expects  to  find  the  so-called  SEM  bundle  in  the  re¬ 
quest.  This  bundle,  as  discussed  in  more  detail  later, 
contains  the  mRSA  half-key,  dfEM ,  encrypted  (for 
the  SEM,  using  its  public  key)  and  signed  (by  the 
CA).  The  bundle  also  contains  the  RSA  public  key 
certificate  for  the  requesting  user.  Once  the  bun¬ 
dle  is  verified,  the  request  is  handled  by  either  the 
mRSAsign  or  mRSAdecrypt  component.  In  case  of  the 
appropriate  signature  request,  the  optional  times¬ 
tamping  service  is  invoked.  If  the  SEM  maintains 
user  state,  the  bundle  is  expected  only  in  the  ini¬ 
tial  request.  The  same  process  as  above  is  followed, 
however,  the  SEM’s  half-key  and  the  user’s  certifi¬ 
cate  are  stored  locally.  In  subsequent  user  requests, 
the  bundle  (if  present)  is  ignored  and  local  state  is 
used  instead. 

The  administrator  communicates  with  the  SEM  via 
the  admin  interface.  The  interface  enables  the  ad¬ 
ministrator  to  manipulate  the  revocation  list. 


4  Security  of  the  SEM  architecture 


We  now  briefly  summarize  the  security  features  of 
mRSA  and  the  SEM  architecture. 

First,  consider  an  attacker  trying  to  subvert  a  user 
(Alice).  The  attacker’s  goal  is  to  decrypt  a  message, 
sent  to  Alice  or  to  forge  Alice’s  signature  on  a  cer¬ 
tain  message.  Recall  that  the  token  sent  back  to 
Alice  is  t  =  xd  mod  N  for  some  value  of  x.  The 
attacker  sees  both  x  and  the  token  t.  In  fact,  since 
there  is  no  authentication  of  the  user’s  request  to  the 
SEM,  the  attacker  can  obtain  this  t  for  any  x  of  its 
choice.  We  claim  that  this  information  is  of  no  use 
to  an  attacker.  After  all,  dsem  is  just  a  random  num¬ 
ber  in  [1,  n]  independent  of  the  rest  of  the  attacker’s 
view.  More  precisely,  we  argue  that  any  attack  pos¬ 
sible  with  the  SEM  architecture  is  also  possible  when 
the  user  uses  standard  RSA.  This  statement  can  be 
proven  using  a  simulation  argument.  In  attacking 
standard  RSA  one  can  simulate  the  SEM  (by  pick¬ 
ing  a  random  integer  dsem  in  [1,  n])  and  thus  use  the 
attack  on  the  SEM  to  mount  an  attack  on  standard 
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RSA.  Furthermore,  the  attacker  cannot  masquerade 
as  the  SEM  since  Alice  checks  all  responses  from  the 
SEM  as  described  in  Section  2.1. 

Suppose  the  attacker  is  able  to  compromise  the  SEM 
and  expose  thejsecret  key  dsem .  This  enables  the  at¬ 
tacker  to  “unrevoke”  revoked,  or  block  possible  fu¬ 
ture  revocation  of  currently  valid,  certificates*.  How- 
ever,  knowledge  of  dsem  does  not  enable  the  attacker 
to  decrypt  messages  or  sign  messages  on  behalf  of 
users.  Nevertheless,  it  is  desirable  to  protect  the 
SEM’s  key.  A  standard  approach  is  to  distribute 
the  key  among  a  number  of  SEM  servers  using  se¬ 
cret  sharing.  Furthermore,  the  key  should  never  be 
reconstructed  at  a  single  location.  To  extract  the 
SEM’s  key  an  attacker  would  need  to  break  into  mul¬ 
tiple  SEM  servers.  When  using  rnRSA,  it  is  possible 
to  distribute  the  SEM’s  secret  in  this  way  using  stan¬ 
dard  techniques  from  threshold  cryptography  [3] . 

Once  Alice’s  key  is  revoked,  she  cannot  decrypt  or 
sign  messages  using  her  private  key.  To;|§how  this, 
we  argue  that,  if  Alice  could  sign  or  decrypt  mes¬ 
sages  using  only  her  share  of  private  key,  then  RSA 
is  insecure. 

Finally,  note  that  each  user  is  given  her  own  ran¬ 
dom  RSA  modulus  n8- .  This  means  that  if  a  number 
of  users  are  compromised  (or  a  number  of  users  col¬ 
lude)  there  is  no  danger  to  other  users.  The  private 
keys  of  the  compromised  users  will  be  exposed,  but 
private  keys  of  all  other  users  will  remain  unaffected. 


5  Implementation 

We  implemented  the  entire  SEM  architecture  for  the 
purposes  of  experimentation  and  validation.  The 
reference  implementation  is  publicly  available.  Fol¬ 
lowing  the  architecture  described  earlier,  the  imple¬ 
mentation  is  composed  of  three  parts: 

1.  CA  and  Admin  Utilities: 

includes  certificate  issuance  and  revocation  in¬ 
terface. 

2.  SEM  daemon: 

SEM  architecture  as  described  in  Section  3 

3.  Client  libraries: 

rnRSA  user  functions  accessible  via  an  API. 


Our  reference  implementation  uses  the  popular 
OpenSSL  [12]  library  as  the  low-level  cryptographic 
platform.  OpenSSL  incorporates  a  multitude  of 
cryptographic  functions  and  large-number  arith¬ 
metic  primitives.  In  addition  to  being  efficient  and 
available  on  many  common  hardware  and  software 
platforms,  OpenSSL  adheres  to  the  common  PKCS 
standards  and  is  in  the  public  domain. 

The  SEM  daemon  and  the  C A/ Admin  utilities  are 
implemented  on  Linux  and  Solaris  while  the  client 
libraries  are  available  on  both  Linux  and  Windows98 
platforms. 

In  the  initialization  phase,  CA  utilities  are  used  to 
set  up  the  RSA  public  key-pair  for  each  client  (user). 
The  set  up  process  follows  the  description  in  Section 
2.  Once  the  rnRSA  parameters  are  generated,  two 
structures  are  exported:  1)  SEM  bundle ,  which  in¬ 
cludes  the  SEM’s  half- key  dfEM ,  and  2)  user  bundle , 
which  includes  d, “  and  the  entire  server  bundle.  The 
format  of  both  SEM  and  user  bundles  Conforms  to 
the  PKCS#7  standard. 

The  server  bundle  is  basically  an  RSA  envelope 
signed  by  the  CA  and  encrypted  with  the  SEM’s 
public  key.  The  client  bundle  is  a  shared-key  en¬ 
velope  also  signed  by  the  CA  and  encrypted  with 
the  user-supplied  key  which  can  be  a  password  or  a 
passphra.se.  (A  user  cannot  be  assumed  to  have  a 
pre-existing  public  key.) 

After  issuance,  the  user  bundle  is  distributed  in  an 
out-of-band  manner  to  the  appropriate  user.  Before 
attempting  any  rnRSA  transactions,  the  user  must 
first  decrypt  and  verify  the  bundle.  A  separate  util¬ 
ity  program  is  provided  for  this  purpose.  With  it, 
the  bundle  is  decrypted  with  the  user-supplied  key, 
the  CA’s  signature  is  verified,  and,  finally,  the  user’s 
new  certificate  and  half-key  are  extracted  and  stored 
locally. 

To  sign  or  decrypt  a  message,  the  user  starts  with 
pending  an  rnRSA  request  with  the  SEM  bundle  pig¬ 
gybacked.  The  SEM  processes  the  request  and  the 
bundle  contained  therein  as  described  in  Section  3. 
(Recall  that  the  SEM  bundle  is  processed  based  on 
the  state  model  of  the  particular  SEM.)  All  rnRSA 
packets  have  a  common  packet  header;  the  payload 
format  depends  on  the  packet  type.  The  packet 
header  is  defined  in  Figure  1. 
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6) 


protocol  identifier.  Set  to 
one  of  the  following: 


REG_REQ_T 

REG_RLY_T 

SIG_REQ_T 

SIG_RLY_T 

DEC_REQ_T 

DEC_RLY_T 


register  request 
register  reply 
signature  request 
signature  reply 
decrypt  request 
decrypt  reply 


MRSA(=1) 


in  current  code 


Figure  1:  rnRSA  Packet  Pleader 


5.1  Email  client  plug-in 

To  demonstrate  the  ease  of  using  the  SEM  architec¬ 
ture  we  implemented  a  plug-in  for  the  Eudora  email 
reader  [15].  When  sending  signed  email  the  plug-in 
reads  the  user  bundle  described  in  the  previous  sec¬ 
tion.  It  obtains  the  SEM  address  from  the  bundle 
and  then  communicates  with  the  SEM  to  sign  the 
email.  The  resulting  signed  email  can  be  verified 
using  any  S/MIME  capable  email  client  such  as  Mi¬ 
crosoft  Outlook.  In  other  wordsjphe  email  recipient 
is  oblivious  to  the  fact,  that  a  SEM  is  used  to  control 
the  sender’s  signing  capabilities. 

Figure  2  shows  a  screen  snap  shot  of  trying  to  send 
signed  email  using  a  revoked  key.  In  this  exam¬ 
ple,  the  plug-in  contacts  the  SEM  and  is  told  that 
the  SEM  will  not  supply  the  token  for  a  revoked 
key.  Consequently,  the  plug-in  displays  a  message 
informing  the  user  that  the  email  cannot  be  signed. 


6  Experimental  Results 

We  conducted  a  number  of  experiments  in  order  to 
evaluate  the  practicality  of  the  proposed  architec¬ 
ture  and  our  implementation. 

We  ran  the  SEM  daemon  on  a  Linux  PC  equipped 
with  an  800  Mhz  Pentium  III  processor.  Two  differ¬ 
ent  clients  were  used.  The  fast  client  was  on  another 
Linux  PC  with  a  930  MHz  Pentium  III.  Both  SEM 
and  fast  client  PC-s  had  256M  of  RAM.  The  slow 
client  was  on  a  Linux  PC  with  466  MHz  Pentium  II 


and  128M  of  RAM.  Although  an  800  Mhz  processor 
is  not  exactly  state-of-the-art,  we  opted  to  err  on  the 
side  of  safety  and  assume  a  relatively  conservatives: 
(i.e. ,  slow)  SEM  platform.  Li  practice,  a  SEM  might 
reside  on  much  faster  hardware  and  is  likely  to  be 
assisted  by  an  RSA  hardware  acceleration  card. 

Each  experiment  involved  one:  thousand  iterations. 
All  reported  timings  are  in  milliseconds  (rounded  to 
the  nearest  0.1  ms).  The  SEM  and  client  PCs  were 
located  in  different  sites  interconnected  by  a  high¬ 
speed  regional  network.  All  protocol  messages  are 
transmitted  over  UDP. 

Client  RSA  key  (modulus)  sizes  were  varied  among 
512,  1024  and  2048  bits.  (Though  it  is  clear  that 
512  is  not  a  realistic  RSA  key  size  any  longer.)  The 
timings  are  only  for  the  rnRSA  sign  operation  since 
rnRSA  decrypt  is  operationally  almost  identical. 


6.1  Communication  Overhead 


In  order  to  gain  precise  understanding  of  our  results, 
we  first  provide  separate  measurements  for  commu¬ 
nication  latency  in  rnRSA.  Recall  that  both  rnRSA 
operations  involve  a  request  from  a  client  followed 
by  a  reply  from  a  SEM.  As  mentioned  aboviSy  the 
test  PCs  were  connected  by  a  high-speed  regional 
network.  We  measured  communication  latency  by 
varying  the  key  size  which  directly  influences  mes¬ 
sage  sizes.  The  results  are  shown  in  Table  1  (mes¬ 
sage  sizes  are  in  bytes).  Latency  is  calculated  as  the 
round-trip  delay  between  the  client  and  the  SEM. 
The  numbers  are  identical  for  both  client  types. 
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Figure  2:  Screen  snapshot  of  SEM  email  plug-in 


Keysize 

Message  Size 

Comm,  latency 

(bits) 

(bytes) 

(ms) 

512 

102 

4.0 

1024 

167 

4.5 

2048 

296 

5.5 

Table  1:  Communication  latency 


6.2  Standard  RSA 


As  a  point  of  comparison,  we  initially  timed  the 
standard  RSA  sign  operation  in  OpenSSL  (Version 
0.9.6)  with  three  different  key  sizes  on  each  of  our 
three  test  PCs.  The  results  are  shown  in  Tables 
2  and  3.  Each  timing  includes  a  message  hash 
computation  followed  by  an  exponentiation.  Ta¬ 
ble  2  reflects  optimized  RSA  computation  where 
the  Chinese  Remainder  Theorem  (CRT)  is  used  to 
speed  up  exponentiation  (essentially  exponentiation 
is  done  modulo  the  prime  factors  rather  than  mod¬ 
ulo  N).  Table  3  reflects  unoptimized  RSA  computa¬ 
tion  without  the  benefit  of  the  CRT.  Taking  advan¬ 
tage  of  the  CRT  requires  knowledge  of  the  factors  (p 
and  q)  of  the  modulus  n.  Recall  that,  in  mRSA,  nei¬ 


ther  the  SEM  nor  the  user  know  the  factorization  of 
the  modulus,  hence,  with  regard  to  its  computation 
cost,  mRSA  is  more  akin  to  unoptimized  RSA. 

As  evident  from  the  two  tables,  the  optimized  RSA 
performs  a  factor  of  3-3.5  faster  for  the  1024-  and 
2048-bit,  moduli  than  the  unoptimized  version.  For 
512-bit,  keys,  the  difference  is  slightly  less  marked. 


6.3  mRSA  Measurements 


The  mRSA  results  are  obtained  by  measuring  the 
time  starting  with  the  message  hash  computation 
by  the  user  (client)  and  ending  with  the  verification 
of  the  signature  by  the  user.  The  measurements  are 
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Keysize 

(bits) 

466  Mhz  PII 
(slow  client.) 

800  Mhz  PHI 
(SEM) 

930  Mhz  PHI 
(fast,  client.) 

512 

2.9 

1.4 

1.4 

1024 

14.3 

7.7 

7.2 

2048 

85.7 

49.4 

42.8 

Table  2:  RSA  results  with  CRT  (in  milliseconds). 


Keysize 

(bits) 

466  Mhz  PII 
(slow  client.) 

800  Mhz  PHI 
(SEM) 

930  Mhz  PHI 
(fast,  client.) 

512 

6.9 

4.0 

3.4 

1024 

43.1 

24.8 

21.2 

2048 

297.7 

169.2 

144.7 

Table  3:  Standard  RSA  results  without  CRT  (in  milliseconds). 


illustrated  in  Table  4. 

It  comes  as  no  surprise  that  the  numbers  for  the  slow 
client  in  Table  4  are  very  close  to  the  unoptimized 
RSA  measurements  in  Table  3.  This  is  because  the 
time  for  an  rnRSA  operation  is  determined  solely  by 
the  client  for  1024-  and  2048-  bit  keys.  With  a  512- 
bit.  key,  the  slow  client  is  fast  enough  to  compute  its 
PSU  in  6.9ms.  This  is  still  under  8.0 ms  (the  sum 
of  4ms  round-trip  delay  and  4ms  RSA  operation  at 
the  SEM). 

The  situation  is  very  different  with  a  fast  client. 
Here,  for  all  key  sizes,  the  timing  is  determined 
by  the  sum  of  the  round-trip  client.-SEM  packet  de¬ 
lay  and  the  service  time  at  the  SEM.  For  instance, 
178.3ms  (clocked  for  2048-bit.  keys)  is  very  close  t.o 
174.7ms  which  is  the  sum  of  5.5ms  communication 
delay  and  169.2ms  unopt.imized  RSA  operation  at 
the  SEM. 

All  of  the  above  measurements  wer#:  taken  with  the 
SEM  operating  in  a.  stateful  mode.  Ri  a.  stateless 
mode,  SEM  incurs  further  overhead  due  to  the  pro¬ 
cessing  of  the  SEM  bundle  for  each  incoming  re¬ 
quest..  This  includes  decryption  of  the  bundle  and 
verification  of  the  CA’s  signature  found  inside.  To 
get.  an  idea,  of  the  rnRSA  overhead  with  a  state¬ 
less  SEM,  we  conclude  the  experiments  with  Table 
5  showing  the  bundle  processing  overhead.  Only 
1024-  and  2048-bit.  SEM  key  size  was  considered. 
(512-bit.  keys  are  certainly  inappropriate  for  a.  SEM.) 
The  CA  key  size  was  constant,  at  1024  bits. 


7  Comparison  of  SEM  with  existing 
certificate  revocation  techniques 


Certificate  revocation  is  a.  well  recognized  problem 
with  the  existing  Public  Key  Infrastructure  (PKI). 
Several  proposals  address  this  problem.  We  briefly 
review  these  proposals  and  compare  them  to  the 
SEM  architecture.  For  each  proposal  we  describe 
how  it.  applies  to  signatures  and  to  encryption.  For 
simplicity  we  use  signed  and  encrypted  Email  as  an 
example  application.  We  refer  to  the  entity  vali¬ 
dating  and  revoking  certificates  as  the  Validation 
Authority  (VA).  Typically,  the  VA  is  the  same  en¬ 
tity  as  the  Certificate  Authority  (CA).  However,  in 
some  cases  these  are  separate  organizations. 

A  note  on  timestamping.  Binding  signature  seman¬ 
tics  (Section  1.3)  for  signature  verification  states 
that.  a.  signature  is  considered  valid  if  the  key  used 
to  generate  the  signature  was  valid  at.  the  time  sig¬ 
nature  generation.  Consequently,  a.  verifier  must, 
establish  exactly  when  a.  signature  was  generated. 
Hence,  when  signing  a.  message,  the  signer  must,  in¬ 
teract.  with  a.  trusted  timestamping  service  to  obtain 
a.  trusted  timestamp  and  a.  signature  over  the  user’s 
(signed)  message.  This  proves  to  any  verifier  that, 
a.  signature  was  generated  at.  a.  specific  time.  All 
the  techniques  discussed  below  require  a.  signature 
to  contain  a.  timestamp  indicating  when  a.  signature 
was  issued.  We  implicitly  assume  this  service.  As 
we  will  see,  there  is  no  need  for  a.  trusted  time  ser¬ 
vice  to  implement,  binding  signature  semantics  with 
the  SEM  architecture. 
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Keysize 

(bits) 

466  Mhz  PII 
(slow  client) 

930  Mhz  PHI 
(fast  client) 

512 

8.0 

9.9 

1024 

45.6 

31.2 

2048 

335.6 

178.3 

Table  4:  Timings  for  rnRSA  (in  milliseconds). 


SEM  key  size 

Bundle  overhead 

1024 

8.1 

2048 

50.3 

Table  5:  Bundle  overhead  in  rnRSA  with  a  SEM  in  a  stateless  mode  (in  milliseconds). 


7.1  Review  of  existing  revocation  tech¬ 
niques 

CRLs  and  A-CRLs:  Certificate  Revocation  Lists 
are  the  most  common  way  to  handle  certificate  revo¬ 
cation.  The  Validation  Authority  (VA)  periodically 
posts  a  signed  list  of  all  revoked  certificates.  These 
lists  are  placed  on  designated  servers  called  CRL 
distribution  points.  Since  these  lists  can  get  quite 
long,  the  VA  may  alternatively  post  a  signed  A-CRL 
which  only  contains  the  list  of  revoked  certificates 
since  the  last  CRL  was  issued.  For  completeness,  we 
briefly  explain  how  CRLs  are  used  in  the  context  of 
signatures  and  encryption: 

-  Encryption:  at  the  time  email  is  sent,  the  sender 

checks  that  the  receiver’s  certificate  is  not  on  the 
current  CRL.  The  sender  then  sends  encrypted 
email  to  the  receiver. 

-  Signatures:  when  verifying  a  signature  on  a  mes¬ 

sage,  the  verifier  checks  that,  at  the  time  that 
the  signature  was  issued,  the  signer’s  certificate 
was  not  on  the  CRT. 

OCSP:  The  Online  Certificate  Status  Protocol 
(OCSP)  [11]  improves  on  CRTs  by  avoiding  the 
transmission  of  long  CRTs  to  every  user  and  by  pro¬ 
viding  more  timely  revocation  information.  To  vali- 
daie  a  specific  certificate  in  OCSP,  the  user  sends  a 
certificate  status  request  to  the  VA.  The  VA  sends 
back  a  signed  response  indicating  whether  the  spec¬ 
ified  certificate  is  currently  revoked.  OCSP  is  used 
as  follows  for  Encryption  and  signatures: 

-  Signatures:  When  verifying  a  signature,  the  ver¬ 

ifier  sends  an  OCSP  query  to  the  VA  to  check 
if  the  corresponding  certificate  is  currently  valid. 
Note  that  the  current  OCSP  protocol  prevents 
one  from  implementing  binding  semantics:  it  is 
not  possible  to  ask  an  OCSP  responder  whether 


a  certificate  was  valid  at  some  time  in  the  past. 
Hopefully  this  will  be  corrected  in  future  versions 
of  the  protocol. 

One  could  potentially  abuse  the  OCSP  protocol 
and  provide  binding  semantics  as  follows.  To  sign 
a  message,  the  signer  generates  the  signature, 
and  also  sends  an  OCSP  query  to  the  VA.  The  VA 
responds  with  a  signed  message  saying  that  the 
certificate  is  currently  valid.  The  signer  appends 
both  the  signature  and  the  response  from  the  VA 
to  the  message.  To  verify  the  signature,  the  ver¬ 
ifier  checks  the  VA’s  signature  on  the  validation 
response.  The  response  from  the  VA  provides 
a  proof  that  the  signer’s  certificate  is  currently 
valid.  This  method  reduces  the  load  on  the  VA: 
it  is  not  necessary  to  contact  the  VA  every  time 
a  signature  is  verified.  Unfortunately,  there  is 
currently  no  infrastructure  to  support  this  mech¬ 
anism. 

-  Encryption:  Every  time  the  sender  sends  an  en¬ 
crypted  message  to  the  receiver  she  sends  an 
OCSP  query  to  the  VA  to  ensure  that  the  re¬ 
ceiver’s  certificate  is  still  valid. 

Certificate  Revocation  Trees:  Kocher  suggested 
an  improvement  over  OCSP  [7].  Since  the  VA  is  a 
global  service  it  must  be  sufficiently  replicated  in  or¬ 
der  to  handle  the  load  of  all  the  validation  queries. 
This  means  the  VA’s  signing  key  must  be  replicated 
across  many  servers  which  is  either  insecure  or  ex¬ 
pensive  (VA  servers  typically  use  tamper-resistance 
to  protect  the  VA’s  signing  key).  Kocher 's  idea  is  to 
have  a  single  highly  Secure  VA  periodically  post  a 
signed  CRL-like  data  structure  to  many  insecure  VA 
servers.  Users  then  query  these  insecure  VA  Servers. 
The  data  structure  proposed  by  Kocher  is  a  hash 
tree  where  the  leaves  are  the  currently  revoked  cer¬ 
tificates  sorted  by  serial  number  (lowest  serial  num- 
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ber  is  the  left  most  leaf  and  the  highest  serial  num¬ 
ber  is  the  right  most  leaf).  The  root  of  the  hash  tree 
is  signed  by  the  VA.  This  hash  tree  data  structure 
is  called  a  Certificate  Revocation  Tree  (CRT). 
When  a  user  wishes  to  validate  a  certificate  CERT 
she  issues  a  query  to  the  closest  VA  server.  Any  inse¬ 
cure  VA  can  produce  a  convincing  proof  that  CERT 
is  (or  is  not)  on  the  CRT.  If  n  certificates  are  cur¬ 
rently  revoked,  the  length  of  the  proof  is  0(log?i). 
In  contrast,  the  length  of  the  validity  proof  in  OCSP 
is  0(1). 

Skip-lists  and  2-3  trees:  One  problem  with 
CRT’s  is  that,  every  time  a  certificate  is  revoked, 
the  entire  CRT  must  be  recomputed  and  distributed 
in  its  entirety  to  the  various  VA  servers.  A  data 
structure  allowing  for  dynamic  updates  would  solve 
this  problem  since  the  secure  VA  would  only  need 
to  send  small  updates  to  the  data  structure  along 
with  a  signature  on  the  new  root  of  the  structure. 
Both  2-3  trees  proposed  by  Naor  and  Nissirn  [10]  and 
skip-lists  proposed  by  Goodrich  [5]  are  natural  data 
structures  for  this  purpose.  Additional  data  struc¬ 
tures  were  proposed  in  [1].  When  a  total  of  n  cer¬ 
tificates  are  already  revoked  and  k  new  certificates 
must  be  revoked  during  the  current  time  period, 
the  size  of  the  update  message  to  the  VA  servers 
is  O(klogn)  (as  opposed  to  O(n)  with  CRT’s).  The 
proof  of  certificate’s  validity  is  0(log?i),  same  as 
with  CRTs. 

7.2  Comparison  with  SEM  architecture 

CRTs  and  OCSP  are  the  most  commonly  deployed 
certificate  revocation  techniques.  Some  positive  ex¬ 
periments  with  skip-lists  are  reported  in  [5].  We 
compare  the  SEM  architecture  with  CRTs  and 
OCSP.  Since  CRT’s  and  skip-lists  are  used  in  the 
same  way  as  OCSP  (i.e. ,  query  a  VA  to  obtain  a 
proof  of  validity)  most  everything  in  our  OCSP  dis¬ 
cussion  applies  to  these  methods  as  well. 

Immediate  revocation:  Suppose  we  use  CRTs  for 
revocation.  Then,  Bob  verifies  a  signature  or  en¬ 
crypts  a  message  he  must  first  download  a  long  CRT 
and  verify  that  the  Alice’s  certificate  is  not  on  the 
CRT.  Note  that  Bob  is  uninterested  in  all  but  one 
certificate  on  the  CRT.  Nevertheless,  he  must  down¬ 
load  the  entire  CRT  since,  otherwise,  the  VA’s  sig¬ 
nature  on  the  CRT  cannot  be  verified.  Since  CRTs 
and  A-CRTs  tend  to  get  long,  they  are  downloaded 
infrequently,  e.g.,  once  a  week  or  month.  As  a  result, 
certificate  revocation  might  only  take  effect  a  month 


after  the  revocation  occurs.  The  SEM  architecture 
solves  this  problem  altogether. 

Suppose  now  that  OCSP  is  usd  for  revocation. 
Whenever  Bob  sends  email  to  Alice  he  first  issues  an 
OCSP  query  to  verify  validity  of  Alice’s  certificate. 
He  then  sends  email  encrypted  with  Alice’s  public 
key.  The  encrypted  email  could  sit  on  Alice’s  email 
server  for  a  few  hours  or  days.  If,  during  this  time, 
Alice’s  key  is  revoked  (e.g.,  because  Alice  is  fired  or 
looses  her  private  key)  there  is  nothing  preventing 
the  holder  of  Alice’s  private  key  from  decrypting  the 
email  after  revocation.  The  SEM  solves  this  prob¬ 
lem  by  disabling  the  private  key  immediately  after 
revocation. 


Implicit  timestamping:  Both  OCSP  and  CRTs 
require  the  signer  to  contact  a  trusted  time  ser¬ 
vice  at  signature  generation  time  to  obtain  a  secure 
timestamp  for  the  signature.  Otherwise,  a  verifier 
cannot  determine  with  certainty  when  the  signature 
was  issued.  If  binding  semantics  are  sufficient,  the 
time  service  is  unnecessary  when  using  the  SEM  ar¬ 
chitecture.  Once  a  certificate  is  revoked,  the  corre¬ 
sponding  private  key  can  no  longer  be  used  to  issue 
signatures.  Therefore,  a  verifier  holding  a  signature 
is  explicitly  assured  that  the  signer’s:  certificate  was 
valid  at  the  time  the  signature  was  generated. 


Shifted  validation  burden:  With  current  PKIs, 
the  burden  of  validating  certificates  is  placed  on:  (1) 
senders  of  encrypted  messages  and  (2)  verifiers  of 
signed  messages.  In  the  SEM  architecture,  the  bur¬ 
den  of  certificate  validation  is  reversed:  (1)  receivers 
of  encrypted  messages  and  (2)  signers  (generators) 
of  signed  messages. 


SEM  Replication  (A  disadvantage):  Since  many 
users  need  to  use  the  SEM  for  decryption  and  sign¬ 
ing,  it  is  natural  to  replicate  it.  However,  replicating 
the  SEM  across  organizations  is  not  recommended 
for  the  same  reason  that  replicating  the  VA  in  OCSP 
is  not  recommended.  Essentially,  the  SEM  gener¬ 
ates  tokens  using  a  private  key  known  only  to  the 
SEM.  The  result  of  exposing  this  key  is  that  an  at¬ 
tacker  could  unrevoke  certificates.  Replicating  the 
SEM  might  make  it  easier  to  expose  the  SEM’s  key. 
Hence,  the  SEM  architecture  is  mainly  applicable 
in  the  same  environments  where  OCSP  is  used,  i.e., 
mainly  medium-sized  organizations.  The  SEM  ar¬ 
chitecture  is  not  geared  towards  the  global  Internet. 
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8  Conclusions 


We  described  a  new  approach  to  certificate  revo¬ 
cation.  Rather  than  revoking  the  user’s  certificate 
our  approach  revokes  the  user’s  ability  to  perform 
cryptographic  operations  such  as  signature  genera¬ 
tion  and  decryption.  This  approach  has  several  ad¬ 
vantages  over  traditional  certificate  revocation  tech¬ 
niques:  (1)  revocation  is  instantaneous  -  the  in¬ 
stant  the  user’s  certificate  is  revoked  the  user  can 
no  longer  decrypt  or  sign  messages,  (2)  when  us¬ 
ing  binding  signature  semantics  there  is  no  need  to 
validate  the  signer’s  certificate  during  signature  ver¬ 
ification,  and  (3)  using  rnRSA  this  revocation  tech¬ 
nique  is  transparent  to  the  peer  -  the  system  gen¬ 
erates  standard  RSA  signatures  and  decrypts  stan¬ 
dards  RSA  encrypted  messages. 

We  implemented  the  SEM  architecture  for  experi¬ 
mentation  purposes.  Our  measurements  of  the  im¬ 
plementation  show  that  signature  and  decryption 
times  are  essentially  unchanged  from  the  user’s  per¬ 
spective.  Therefore,  we  believe  this  architecture  is 
appropriate  for  a  medium-size  organization  where 
tight  control  of  security  capabilities  is  desired.  The 
SEM  architecture  is  not  designed  for  the  global  In¬ 
ternet. 
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Abstract 

We  show  how  to  efficiently  generate  RSA  keys  on  a  low  power  handheld  device  with  the  help 
of  an  untrusted  server.  Most  of  the  key  generation  work  is  offloaded  onto  the  server.  However,  the 
server  learns  no  information  about  the  key  it  helped  generate.  We  experiment  with  our  techniques 
and  show  they  result  in  up  to  a  factor  of  5  improvement  in  key  generation  time.  The  resulting 
RSA  key  looks  like  an  RSA  key  for  paranoids.  It  can  be  used  for  encryption  and  key  exchange,  but 
cannot  be  used  for  signatures. 


1  Introduction 

In  recent  years  we  have  seen  an  explosion  in  the  number  of  applications  for  handheld  devices.  Many 
of  these  applications  require  the  ability  to  communicate  securely  with  a  remote  device  over  an  authen¬ 
ticated  channel.  Example  applications  include:  (1)  a  wireless  purchase  using  a  cell  phone,  (2)  remote 
secure  synchronization  with  a  PDA,  (3)  using  a  handheld  device  as  an  authentication  token  [2],  and 
(4)  handheld  electronic  wallets  [3].  Many  of  these  handheld  applications  require  the  ability  to  issue 
digital  signatures  on  behalf  of  their  users. 

Currently,  the  RSA  cryptosystem  is  the  most  widely  used  cryptosystem  for  key  exchange  and  digital 
signatures:  SSL  commonly  uses  RSA-based  key  exchange,  most  PKI  products  use  RSA  certificates, 
etc.  Unfortunately,  RSA  on  a  low  power  handheld  device  is  somewhat  problematic.  For  example, 
generating  a  1024  bit  RSA  signature  on  the  PalmPilot  takes  approximately  30  seconds.  Nevertheless, 
since  RSA  is  so  commonly  used  on  servers  and  desktops  it  is  desirable  to  improve  its  performance  on 
handhelds. 

In  this  paper  we  consider  the  problem  of  generating  RSA  keys.  Generating  a  1024  bit  RSA  key 
on  the  PalmPilot  can  take  as  long  as  15  minutes.  The  device  locks  up  while  generating  the  key  and 
is  inaccessible  to  the  user.  For  wireless  devices  battery  life  time  is  a  concern.  Consider  a  user  who  is 
given  a  new  cellphone  application  while  traveling.  The  application  may  need  to  generate  a  key  before 
it  can  function.  Generating  the  key  while  the  user  is  traveling  will  lock  up  the  cellphone  for  some  time 
and  may  completely  drain  the  batteries. 

The  obvious  solution  is  to  allow  the  handheld  to  communicate  with  a  desktop  or  server  and  have 
the  server  generate  the  key.  The  key  can  then  be  downloaded  onto  the  handheld.  The  problem  with 
this  approach  is  that  the  server  learns  the  user’s  private  key.  Consequently,  the  server  must  be  trusted 
by  the  user.  This  approach  limits  mobility  of  the  handheld  application  since  users  can  only  generate  a 
key  while  communicating  with  their  home  domain.  We  would  like  to  enable  users  to  quickly  generate 
an  RSA  key  even  when  they  cannot  communicate  with  a  trusted  machine. 

*  Supported  by  nsf  CCR-9732754. 
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Figure  1:  A  two  server  configuration 

We  study  the  following  question:  can  we  speed  up  RSA  key  generation  on  a  handheld  with  the 
help  of  an  untrusted  server!  Our  goal  is  to  offload  most  of  the  key  generation  work  onto  the  untrusted 
server.  However,  once  the  key  is  generated  the  server  should  have  no  information  about  the  key  it 
helped  generate.  This  way  the  handheld  can  take  advantage  of  the  server’s  processing  power  without 
compromising  the  security  of  its  keys. 

Our  best  results  show  how  to  speed  up  the  generation  of  unbalanced  RSA  keys.  We  describe  these 
keys  and  explain  how  they  are  used  in  the  next  section.  Our  results  come  in  two  flavors.  First,  we 
show  how  to  speed  up  key  generation  with  the  help  of  two  untrusted  servers.  We  assume  that  the 
two  servers  are  unable  to  share  information  with  each  other.  For  instance,  the  two  untrusted  servers 
may  be  operated  by  different  organizations.  Using  two  untrusted  servers  we  are  able  to  speed  up  key 
generation  by  a  factor  of  5.  We  then  show  that  a  single  untrusted  server  can  be  used  to  speed  up 
key  generation  by  a  factor  of  2.  In  Section  4  we  discuss  speeding  up  normal  RSA  key  generation  (as 
opposed  to  unbalanced  keys) . 

We  implemented  and  experimented  with  all  our  algorithms.  We  used  the  PalmPilot  as  an  example 
handheld  device  since  it  is  easy  to  program.  Clearly  our  techniques  apply  to  any  low  power  handheld: 
pagers,  cell  phones,  MP3  players,  PDA’s,  etc.  In  our  implementation,  the  PalmPilot  connects  to  a 
desktop  machine  using  the  serial  port.  When  a  single  server  is  used  to  help  generate  the  key,  the 
pilot  communicates  with  the  desktop  using  TCP/IP  over  the  serial  link.  The  desktop  functions  as 
the  helping  server.  Note  that  there  is  no  need  to  protect  the  serial  connection.  After  all,  since  the 
desktop  learns  no  information  about  the  key  it  helped  generate,  an  attacker  snooping  the  connection 
will  also  learn  nothing.  When  two  servers  are  used,  the  desktop  functions  as  a  gateway  enabling  the 
pilot  to  communicate  with  the  two  servers.  In  this  case,  communication  between  the  pilot  and  servers 
is  protected  by  SSL  to  prevent  eavesdropping  by  the  gateway  machine,  and  to  prevent  one  server  from 
listening  in  on  communication  intended  for  the  other.  Typically,  the  gateway  machine  functions  as 
one  of  the  two  servers,  as  shown  in  Figure  1. 

1.1  Timing  cryptographic  primitives  on  the  PalmPilot 

For  completeness  we  list  some  running  times  for  cryptographic  operations  on  the  PalmPilot.  We  used 
the  Palm  V  which  uses  a  16.6MhZ  Dragonball  processor.  Running  times  for  DES,  SHA-1,  and  RSA 
were  obtained  using  a  port  of  parts  of  SSLeay  to  the  PalmPilot  started  by  Ian  Goldberg. 
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Algorithm 

Time 

Comment 

DES  encryption 

SHA-1 

4.9ms/block 

2.7ms/block 

1024  bit  RSA  key  generation 

15  minutes  on  average 

1024  bit  RSA  sig.  generation 

27.8  sec. 

1024  bit  RSA  sig.  verify 

0.758  sec. 

e  =  3 

1024  bit  RSA  sig.  verify 

1.860  sec. 

e  =  65537 

2  Preliminaries 

2.1  Overview  of  RSA  key  generation 

As  a  necessary  background  we  give  a  brief  overview  of  RSA  key  generation.  Recall  that  an  RSA  key  is 
made  up  of  an  n-bit  modulus  N  =  pq  and  a  pair  of  integers  d,  called  the  private  exponent,  and  e,  called 
the  public  exponent.  Typically,  N  is  the  product  of  two  large  primes,  each  nj 2  bits  long.  Throughout 
the  paper  we  focus  on  generating  a  1024  bit  key  (i.e.  n  =  1024).  The  algorithm  to  generate  an  RSA 
key  is  as  follows: 

Step  1:  Repeat  the  following  steps  until  two  primes  p ,  q  are  found: 

a.  Candidate  Pick  a  random  512  bit  candidate  value  p. 

b.  Sieve  Using  trial  division,  check  that  p  is  not  divisible  by  any  small  primes  (i.e.  2, 3, 5, 7, 

etc.). 

c.  Test  Run  a  probabilistic  primality  test  on  the  candidate.  For  simplicity  one  can  view  the 

test  as  checking  that  gb’-1)/2  =  ±1  (mod  p),  where  g  is  a  random  value  in  1 . .  .p  —  1.  All 
primes  will  pass  this  test,  while  a  composite  will  fail  with  overwhelming  probability  [10]. 

Step  2:  Compute  the  product  N  =  pq  (the  product  is  1024  bits  long). 

Step  3  :  Pick  encryption  and  decryption  exponents  e  and  d  where  e  •  d  =  1  mod  <p(N)  and  ip(N)  = 
N  —  p  —  q  +  1. 

The  bulk  of  the  key  generation  work  takes  place  in  step  (1).  Once  the  two  primes  p  and  q  are  found, 
steps  (2)  and  (3)  take  negligible  work.  We  note  that  trial  division  (step  lb)  is  frequently  optimized 
by  using  a  sieving  algorithm.  Sieving  works  as  follows:  once  the  candidate  p  is  chosen  in  step  (la), 
the  sieve  is  used  to  quickly  find  the  closest  integer  to  p  that  is  not  divisible  by  any  small  primes.  The 
candidate  p  is  then  updated  to  be  the  integer  found  by  the  sieve.  Throughout  the  paper  we  use  a 
sieving  algorithm  attributed  to  Phil  Zimmerman. 

Our  goal  is  to  improve  the  performance  of  step  (1).  Within  step  (1),  the  exponentiation  in  step  (lc) 
dominates  the  running  time.  Our  goal  is  to  offload  the  primality  test  to  the  server  without  exposing 
any  information  about  the  candidate  being  tested.  Hence,  the  question  is:  how  can  we  test  that 
gp~ 1  mod  p  =  1  with  the  help  of  a  server  without  revealing  any  information  about  pi  To  do  so  we 
must  show  how  to  carry  out  the  exponentiation  while  solving  two  problems:  (1)  hiding  the  modulus 
p ,  and  (2)  hiding  the  exponent  p  —  1. 
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2.2  Unbalanced  RSA  keys 


Our  best  results  show  how  to  speed  up  the  generation  of  unbalanced  RSA  keys.  An  unbalanced  key 
uses  a  modulus  N  of  the  form  N  =  p  •  R  where  p  is  a  512  bit  prime  and  R  is  a  4096  bit  random 
number.  One  can  show  that  with  high  probability  R  has  a  prime  factor  that  is  at  least  512  bits  long 
(the  probability  that  it  does  not  have  such  a  factor  is  less  than  1/224).  Consequently,  the  resulting 
modulus  N  is  as  hard  to  factor  as  a  standard  modulus  N  =  pq. 

An  unbalanced  key  is  used  in  the  same  way  as  standard  RSA  keys.  The  public  key  is  (e,  N )  and 
the  private  key  is  (d,N).  We  require  that  e  •  d  =  1  modp  —  1.  Suppose  p  is  m-bits  long.  The  system 
can  be  used  to  encrypt  messages  shorter  than  m  bits.  As  in  standard  RSA,  to  encrypt  a  message  M, 
whose  length  is  much  shorter  than  m  bits,  the  sender  first  applies  a  randomized  padding  mechanism, 
such  as  OAEP  [4,  9].  The  padding  mechanism  results  in  an  m  —  1  bit  integer  P  (note  that  P  <  p). 
The  sender  then  constructs  the  ciphertext  by  computing  C  =  Pe  mod  N.  Note  that  the  ciphertext  is 
as  big  as  N.  To  decrypt  a  ciphertext  (7,  the  receiver  first  computes  Cp  =  C  mod  p  and  then  recovers 
P  by  computing  P  =  mod  p.  The  plaintext  M  is  then  easily  extracted  from  P.  Since  decryption 
is  done  modulo  p  it  is  as  fast  as  standard  RSA. 

The  technique  described  above  for  using  an  unbalanced  key  is  similar  to  Shamir’s  “RSA  for  para¬ 
noids”  [11].  It  shows  that  unbalanced  keys  can  be  used  for  encryption/decryption  and  key  exchange. 
Unfortunately,  unbalanced  keys  cannot  be  used  for  digital  signatures.  We  note  that  some  attacks 
against  RSA  for  paranoids  have  been  recently  proposed  [5] .  However,  these  attacks  do  not  apply  when 
one  uses  proper  padding  prior  to  encryption.  In  particular,  when  OAEP  padding  is  used  [4]  the  attacks 
cannot  succeed  since  the  security  of  OAEP  (in  the  random  oracle  model)  only  relies  on  the  fact  that 
the  function  /  :  {0, . . . ,  2m_1}  ->  defined  by  f(x)  =  xe  mod  N  is  a  one-to-one  trapdoor  one  way 
function. 


3  Generating  an  unbalanced  RSA  key  with  the  help  of  untrusted 
servers 

We  show  how  RSA  key  generation  can  be  significantly  sped  up  by  allowing  the  PalmPilot  to  interact 
with  untrusted  servers.  At  the  end  of  the  computation  the  servers  should  know  nothing  about  the  key 
they  helped  generate.  We  begin  by  showing  how  two  untrusted  servers  can  help  the  Pilot  generate 
RSA  keys.  The  assumption  is  that  these  two  servers  cannot  exchange  information  with  each  other. 
To  ensure  that  an  attacker  cannot  eavesdrop  on  the  network  and  obtain  the  information  being  sent 
to  both  servers,  our  full  implementation  protects  the  connection  between  the  Pilot  and  the  servers 
using  SSL.  Typically,  the  machine  to  which  the  pilot  is  connected  can  be  used  as  one  of  the  untrusted 
servers  (Figure  1).  We  then  show  how  to  speed  up  key  generation  with  the  help  of  a  single  server.  In 
this  case  there  is  no  need  to  protect  the  connection. 

3.1  Generating  keys  with  the  help  of  two  servers 

Our  goal  is  to  generate  a  modulus  of  the  form  N  =  pR  where  p  is  a  512-bit  prime  and  R  is  a  4096-bit 
random  number.  To  offload  the  primality  test  onto  the  servers  we  must  hide  the  modulus  p  and  the 
exponent  p  —  1.  To  hide  the  modulus  p  we  intend  to  multiply  it  by  a  random  number  R  and  send  the 
resulting  N  =  pR  to  the  servers.  The  server  will  perform  computations  modulo  N  =  pR.  If  it  turns 
out  that  p  is  prime,  then  sending  N  to  the  servers  does  not  expose  any  information  about  p  or  R.  If 
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p  is  not  prime  we  start  over.  To  hide  the  exponent  p  —  1  used  in  the  primality  test  we  intend  to  share 
it  among  the  two  servers.  Individually,  neither  one  of  the  servers  will  learn  any  information. 

Our  algorithm  for  generating  an  unbalanced  RSA  modulus  N  =  pR  is  as  follows.  The  algorithm 
repeats  the  following  steps  until  an  unbalanced  key  is  generated: 

Step  1  :  Pilot  generates  a  512  bit  candidate  p  that  is  not  divisible  by  small  primes  and  a  4096  bit 
random  number  R.  We  require  that  p  =  3  mod  4. 

Step  2  :  Pilot  computes  N  =  p  ■  R. 

Step  3  :  Pilot  picks  random  integers  si  and  S2  in  the  range  [— p,p]  such  that  .sq  +  $2  = 
also  picks  a  random  g  E  1**N. 

Step  4:  Pilot  sends  (N,g,s  1)  to  server  1  and  (IV,  (7,-32)  to  server  2. 

Step  5  :  Server  1  computes  X\  =  gsi  mod  N.  Server  2  computes  X‘>  =  g(  S2;  mod  N 
X\  and  X->  are  sent  back  to  the  pilot. 

Step  6  :  Pilot  checks  whether  X\  =  ±Ab  mod  p.  If  equality  holds,  then  N  =  pR  is  declared  as  a 
potential  unbalanced  RSA  modulus.  Otherwise,  the  algorithm  is  restarted  in  Step  1. 

Step  7:  The  Pilot  locally  runs  a  probabilistic  primality  test  to  verify  that  p  is  prime.  This  is  done  to 
ensure  that  the  servers  returned  correct  values. 

First,  we  verify  the  soundness  of  the  algorithm.  In  step  6  the  Pilot  verifies  that  gsi  -gS2  =  g''  v~ 1  'l;/‘  = 
±1  modp.  If  the  test  is  satisfied  then  p  is  very  likely  to  be  prime.  Then  step  7  ensures  that  p  is  in 
fact  prime  and  that  the  servers  did  not  respond  incorrectly.  When  generating  a  1024  bit  RSA  key,  a 
single  primality  test  takes  little  time  compared  to  the  search  for  a  512  bit  prime.  Hence,  Step  7  adds 
very  little  to  the  total  running  time. 

During  the  search  for  the  prime  p,  the  only  computation  carried  out  by  the  pilot  is  the  probable 
prime  generation  and  the  computation  of  si  and  s 2.  The  time  to  construct  sq  and  .sq  is  negligible. 
On  the  other  hand,  generating  the  probable  prime  p  requires  a  sieve  to  ensure  that  p  is  not  divisible 
by  small  factors.  As  we  shall  see  in  Section  5  the  sieve  is  the  bottleneck.  This  is  unusual  since  in 
standard  RSA  modulus  generation  sieving  takes  only  a  small  fraction  of  the  entire  computation.  We 
use  a  sieving  method  attributed  to  Phil  Zimmerman.  We  note  that  faster  sieves  exist,  but  they  result 
in  an  insecurity  of  our  algorithm. 

Security  To  analyze  the  security  properties  of  the  algorithm  we  must  argue  that  the  untrusted 
servers  learn  no  information  of  value  to  them.  During  the  search  for  the  RSA  modulus  many  candidates 
are  generated.  Since  these  candidates  are  independent  of  each  other,  any  information  the  servers  learn 
about  rejected  candidates  does  not  help  them  in  attacking  the  final  chosen  RSA  modulus.  Once  the 
final  modulus  N  =  pR  is  generated  in  Step  2,  each  server  is  sent  the  value  of  N  and  st  where  i  is  either 
1  or  2.  The  modulus  N  will  become  public  anyhow  (it  is  part  of  the  public  key)  and  hence  reveals  no 
new  information.  Now,  assuming  servers  1  and  2  cannot  communicate,  the  value  sq  is  simply  a  random 
number  (from  Server  l’s  point  of  view).  Server  1  could  have  just  as  easily  picked  a  random  number 
in  the  range  [—  N,  N]  itself.  Hence,  .sq  reveals  no  new  information  to  Server  1  (formally,  a  simulation 
argument  shows  that  sq  reveals  at  most  two  bits).  The  same  holds  for  Server  2.  Hence,  as  long  as 
Server  1  and  Server  2  cannot  communicate,  no  useful  information  is  revealed  about  the  factorization 
of  N.  We  note  that  if  the  servers  are  able  to  communicate,  they  can  factor  N. 


(. P  ~  l)/2.  It 


.  Both  results 


100 


Performance  The  number  of  iterations  until  a  modulus  is  found  is  identical  to  local  generation  of 
an  (unbalanced)  modulus  on  the  PalmPilot.  However,  each  iteration  is  much  faster  than  the  classic 
RSA  key  generation  approach  of  Section  2.1.  After  all,  we  offloaded  the  expensive  exponentiation  to 
a  fast  Pentium  machine.  As  we  shall  see  in  Section  5.2,  the  total  running  time  is  reduced  by  a  factor 
of  5. 

3.2  Generating  keys  with  the  help  of  a  single  server 

Next,  we  show  how  a  single  untrusted  server  can  be  used  to  reduce  the  time  to  generate  an  RSA  key 
on  the  PalmPilot.  Once  the  key  is  generated,  the  server  has  no  information  regarding  the  key  it  helped 
generate.  Typically,  the  pilot  connects  to  the  helping  server  directly  through  the  serial  or  infrared 
ports. 

As  before  we  need  to  compute  gO-1)/2  mod  p  to  test  whether  p  is  prime.  Our  technique  involves 
reducing  the  size  of  the  exponent  using  the  help  of  the  server  and  hence  speeding  up  exponentiation 
on  the  pilot.  The  algorithm  repeats  the  following  steps  until  an  unbalanced  modulus  is  found: 

Step  1  :  Pilot  generates  a  512  bit  candidate  p  that  is  not  divisible  by  small  primes  and  a  4096  bit 
random  number  R.  We  require  that  p  =  3  mod  4. 

Step  2  :  Pilot  computes  N  =  p  ■  R.  It  picks  a  random  g 

Step  3  :  Pilot  picks  a  random  160  bit  integer  r  and  a  random  512  bit  integer  a.  It  computes  z  = 
r  +  a(p-  l)/2. 

Step  4:  Pilot  sends  (IV,  g ,  z)  to  the  server. 

Step  5  :  The  server  computes  X  =  gz  mod  N  and  sends  X  back  to  the  Pilot. 

Step  6  :  Pilot  computes  Y  =  gr  mod  p. 

Step  7:  Pilot  checks  if  X  =  ±Y  mod  p.  If  so  then  the  algorithm  is  finished  and  N  =  pR  is  declared 
as  a  potential  unbalanced  RSA  modulus.  Otherwise,  the  algorithm  is  restarted  in  Step  1. 

Step  8:  The  Pilot  locally  runs  a  probabilistic  primality  test  to  verify  that  p  is  prime. 

To  verify  soundness  observe  that  N  will  make  it  to  step  8  only  if  X  =  ±Y  i.e.  gr+a(p~1)/'2  = 
±gr  mod  p.  As  before,  this  condition  is  always  satisfied  if  p  is  prime.  The  test  will  fail  with  over¬ 
whelming  probability  if  p  is  not  prime.  Hence,  once  step  8  is  reached  the  modulus  N  =  pR  is  very 
likely  to  be  an  unbalanced  modulus.  The  test  is  Step  8  takes  little  time  compared  to  the  entire  search 
for  the  512-bit  prime. 


Performance  Since  we  are  generating  an  unbalanced  modulus  the  number  of  iterations  until  N  is 
found  is  the  same  as  in  local  generation  of  such  a  modulus  on  the  PalmPilot.  Within  each  iteration 
the  Pilot  generates  p  and  R  using  a  sieve  and  then  computes  Y  =  gr  mod  p  (in  step  6).  However,  r  is 
only  160  bits  long.  This  is  much  shorter  than  when  a  key  is  generated  without  the  help  of  a  server. 
In  that  case  the  Pilot  has  to  compute  an  exponentiation  where  the  exponent  is  512  bits  long.  Hence, 
we  reduce  the  exponentiation  time  by  approximately  a  factor  of  three.  Total  key  generation  time  is 
reduced  by  a  factor  of  2,  due  to  the  overhead  of  sieving. 
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Recall  that  in  Step  6  the  Pilot  computes  Y  =  gr  mod  p  where  r  is  a  160-bit  integer.  This  step  can 
be  further  sped  up  with  the  help  of  the  server.  Let  A  =  240  and  write  r  =  ro  +  r  i  A  +  r^A2  +  r^A3 
where  ro,  r\,  are  all  in  the  range  [0,  A],  In  Step  5  the  server  could  send  back  the  vector  R  = 
(gA ,  gA2 ,  gA^)  mod  N  in  addition  to  sending  X.  Let  R  =  (R\,  R2,  R3).  Then  in  Step  6  the  Pilot  only 
has  to  compute  Y  =  gr°  •  R\ 1  •  R'2  •  Rr33  mod  p.  Using  Simultaneous  Multiple  Exponentiation  [7,  p. 
617]  Step  6  can  now  be  done  in  approximately  half  the  time  of  computing  Y  =  gr  mod  p  on  the  Pilot 
directly.  This  improvement  reduces  the  total  exponentiation  time  on  the  Pilot  by  an  additional  factor 
of  2  . 

Security  In  the  last  iteration,  when  the  final  p  and  R  are  chosen,  the  server  learns  the  value  z  = 
a(p  —  1)  +  r.  Although  z  is  a  “random  looking”  1024  bit  number,  it  does  contain  some  information 
about  p.  In  particular,  z  mod p  —  1  is  very  small  (only  160  bits  long).  The  question  is  whether  z  helps 
an  adversary  break  the  resulting  key.  The  best  known  algorithm  for  doing  so  requires  2r/2  modular 
exponentiations.  Due  to  our  choice  of  160  bits  for  r,  the  algorithm  has  security  of  approximately 
280.  This  is  good  enough  since  a  1024  bits  RSA  key  offers  security  of  280  anyhow.  Nevertheless, 
the  security  of  the  scheme  is  heuristic  since  it  depends  on  the  assumption  that  no  faster  algorithm 
exists  for  factoring  N  given  z.  More  precisely,  the  scheme  depends  on  the  following  “(p  —  l)-multiple 
assumption” : 

(p  —  1) -multiple  assumption:  Let  An  be  the  set  of  integers  N  =  pq  where  p  and  q  are  both  n-bit  primes. 
Let  to  be  an  integer  so  that  the  fastest  algorithm  for  factoring  a  random  element  N  E  An  runs  in  time 
at  least  2 ml'2.  Then  the  two  distributions:  (N,r  +  a(p  —  l)/2)  and  (N,x)  cannot  be  distinguished  with 
non-negligible  probability  by  an  algorithm  whose  running  time  is  less  than  2 m/2 .  Here  N  is  randomly 
chosen  in  An,  a  is  randomly  chosen  in  [0,p],  r  is  randomly  chosen  in  [0, 2m],  and  x  is  randomly  chosen 
in  [0,p2/2], 

Based  on  the  (p  —  l)-multiple  assumption,  the  integer  z  given  to  the  server  contains  no  more 
statistical  information  than  a  random  number  in  the  range  [O.p2].  Hence,  the  server  learns  no  new 
useful  information  from  z. 

As  before,  since  the  generated  key  is  an  unbalanced  key  it  can  only  be  used  for  encryption/decryption 
and  key  exchange.  It  cannot  be  used  for  signatures. 


4  Generating  standard  RSA  keys 

One  could  wonder  whether  the  techniques  described  in  the  previous  sections  can  be  used  to  speed  up 
generation  of  standard  RSA  keys.  We  show  that  at  the  moment  these  techniques  do  not  appear  to 
improve  the  generation  time  for  a  1024  bit  key.  For  shorter  keys,  e.g.  512  bits  keys,  we  get  a  small 
improvement.  In  what  follows  we  show  how  to  generate  a  normal  RSA  key,  N  =  pq,  with  the  help  of 
two  servers. 

We  wish  to  generate  an  RSA  modulus  N  =  pq  where  p  and  q  are  each  512-bits  long.  As  before, 
we  wish  to  offload  the  primality  test  to  the  servers.  To  do  so  we  must  hide  the  moduli  p  and  q  and 
the  exponents  p  —  1  and  q  —  1.  The  basic  idea  is  to  simultaneously  test  primality  of  both  p  and  q.  For 
each  pair  of  candidates  p  and  q  the  Pilot  computes  N  =  pq  and  sends  N  to  the  servers.  The  servers 
carry  out  the  exponentiations  modulo  N.  To  hide  the  exponents  p—  1  and  q  —  1  we  share  them  among 
the  two  servers  as  in  the  last  section. 

The  resulting  algorithm  is  similar  to  that  for  generating  unbalanced  keys.  In  fact,  the  server-side  is 
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identical.  The  algorithm  works  as  follows.  Repeat  the  following  steps  until  a  standard  RSA  modulus 
is  found: 

Step  1  :  Pilot  generates  two  candidates  p.  q  so  that  neither  one  is  divisible  by  small  primes.  We  refer 
to  p  and  q  as  probable  primes. 

Step  2  :  Pilot  computes  N  =  p  ■  q  and  ip(N)  —  N  —  p  —  q  +  1.  Pilot  picks  a  random  g  E  Z*N. 

Step  3  :  Pilot  picks  random  integers  ipi  and  ip2  in  the  range  [— JV,  JV]  such  that  +  ip2  =  <j>(JV)/4. 

Step  4:  Pilot  sends  (JV,  <7,  i)  to  server  1  and  (JV,  <7,  — 2)  to  server  2. 

Step  5  :  Server  1  computes  X\  =  g'pl  (mod  N).  Server  2  computers  X2  =  g  !p'2  (mod  JV).  Both 

results  Xi  and  X2  are  sent  back  to  the  pilot. 

Step  6  :  Pilot  checks  if  X\  =  ±W;  mod  N.  If  so,  the  algorithm  is  finished  and  N  =  pq  is  declared  as 
a  potential  RSA  modulus.  Otherwise,  the  algorithm  is  restarted  in  Step  1. 

Step  7:  The  Pilot  locally  runs  a  probabilistic  primality  test  to  verify  that  p  and  q  are  prime.  This  is 
done  to  ensure  that  the  servers  returned  correct  values. 

First,  we  verify  soundness  of  the  algorithm.  In  step  6  the  Pilot  is  testing  that  X\  =  TA'^,  namely 
that  gPl  =  g ~p>2  mod  N.  That  is,  we  check  that  —  g<p(N)/ 4  _  -j-i  mocl  JV.  Clearly,  this  condition 

holds  if  p  and  q  are  both  primes.  Furthermore,  it  will  fail  with  overwhelming  probability  if  either  p 
or  q  are  not  prime.  Hence,  Step  7  is  reached  only  if  N  =  pq  is  extremely  likely  to  be  a  proper  RSA 
modulus.  Step  7  then  locally  ensures  that  p  and  q  are  primes. 

Security  To  analyze  the  security  properties  of  the  algorithm  we  must  argue  that  the  untrusted 
servers  learn  no  information  of  value  to  them.  During  the  search  for  the  RSA  modulus  many  candidates 
are  generated.  Since  these  candidates  are  independent  of  each  other,  any  information  the  servers  learn 
about  rejected  candidates  does  not  help  them  in  attacking  the  final  chosen  RSA  modulus.  Once  the 
final  modulus  N  =  pq  is  generated  in  Step  2,  each  server  is  sent  the  value  of  N  and  where  i  is  either 
1  or  2.  The  modulus  N  will  become  public  anyhow  (it  is  part  of  the  public  key)  and  hence  reveals 
no  new  information.  Now,  assuming  servers  1  and  2  cannot  communicate,  the  value  ipi  is  simply  a 
random  number  (from  Server  l’s  point  of  view).  Server  1  could  have  just  as  easily  picked  a  random 
number  in  the  range  [— JV,  JV]  itself.  Hence,  <pi  reveals  no  new  information  to  Server  1.  As  long  as 
Server  1  and  Server  2  cannot  communicate,  no  useful  information  is  revealed  about  the  factorization 
of  JV.  If  the  servers  are  able  to  communicate,  they  can  factor  JV. 


Performance  Each  iteration  in  our  algorithm  is  much  faster  than  the  classic  RSA  key  generation 
approach  of  Section  2.1  —  we  offloaded  the  expensive  exponentiation  to  a  fast  Pentium  machine. 
Unfortunately,  the  number  of  iterations  required  until  an  RSA  modulus  is  found  is  higher.  More 
precisely,  suppose  in  the  classic  approach  one  requires  k  iterations  on  average  until  a  512-bit  prime 
is  found.  Then  the  total  number  of  iterations  to  find  two  primes  is  2k  on  average.  In  contrast,  in 
our  approach  both  p  and  q  must  be  simultaneously  prime.  Hence,  k 2  iterations  are  required.  We 
refer  to  this  effect  as  a  quadratic  slowdown.  When  generating  a  1024  bit  modulus  the  value  of  k  is 
approximately  14.  So  even  though  we  are  able  to  speed  up  each  iteration  by  a  factor  of  5,  there  are 
seven  times  as  many  iterations  on  average.  Therefore  when  generating  a  standard  1024  bit  key  these 
techniques  do  not  improve  the  running  time.  When  generating  a  shorter  key,  e.g.  a  512  bit  key,  the 
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quadratic  slowdown  penalty  is  less  severe  since  k  is  smaller  (9  rather  than  14).  For  such  short  keys 
we  obtain  a  small  improvement  in  performance. 

Similarly,  when  generating  keys  with  the  help  of  a  single  server,  the  quadratic  slowdown  outweighs 
the  reduction  in  time  per  iteration.  It  is  an  open  problem  to  speed  up  server  aided  generation  of 
standard  RSA  keys. 

5  Experiments  and  implementation  details 

5.1  Implementation  details 

The  two  main  components  of  our  implementation  were  the  cryptographic  and  networking  modules. 
SSLeay  provided  for  the  cryptographic  code  on  both  the  server  (Pentium  II  400Mhz)  and  PalmPilot 
side.  In  the  case  of  the  Pilot,  we  used  SSLeay  code  that  had  been  previously  ported  by  Ian  Goldberg. 

5.1.1  Networking 

We  connect  the  pilot  to  a  Windows  NT  gateway  running  RAS  (Remote  Access  Service)  through  a 
serial-to-serial  interface.  The  function  of  the  gateway  was  to  provide  TCP /IP  access  to  the  network. 

In  our  single  server  implementation,  we  used  the  gateway  as  our  assisting  server  while  in  our  dual 
server  implementation,  we  used  the  gateway  and  another  local  machine. 

Our  networking  layer  abstracts  the  secure  communication  of  Biglntegers  to  and  from  the  PalmPilot. 
The  network  layer  packs  a  number  of  Biglntegers  into  a  buffer  and  sends  the  entire  buffer  at  once. 
The  receiving  side  unpacks  the  buffer  and  processes  it  as  required. 

5.2  Experiments 

Tables  1  and  2  show  the  results  we  obtained  when  generating  512,  768  and  1024  bit  RSA  keys.  The 
network  traffic  column  measures  the  amount  of  data  (in  bytes)  exchanged  between  the  Pilot  and  the 
servers.  We  generate  keys  using  three  methods: 

(1)  Local:  Key  generated  locally  on  the  Pilot  (no  interaction  with  a  server). 

(2)  One  server:  Pilot  aided  by  a  single  untrusted  server. 

(3)  Two  servers:  Pilot  aided  by  two  untrusted  servers. 

As  expected  we  see  that  generating  unbalanced  keys  with  the  aid  of  one  or  two  servers  leads  to 
a  performance  improvement  over  generating  keys  locally  on  the  PalmPilot.  The  rest  of  this  section 
discusses  these  experimental  results. 

We  note  that  the  key  factor  that  determines  the  time  it  takes  to  generate  an  RSA  key  is  the 
time  per  iteration  (the  time  to  sieve  and  exponentiate  one  probable  prime  p).  This  number  is  more 
meaningful  than  the  total  running  since  since  the  total  time  has  a  high  variance.  More  precisely,  the 
number  of  iterations  until  a  prime  is  found  has  high  variance.  Our  tables  state  the  average  number  of 
iterations  we  obtained. 

In  our  experiments,  we  carried  out  trial  division  on  a  candidate  prime  using  the  first  2048  primes 
(upto  approximately  17,000).  In  all  our  experiments  we  observed  that  the  server’s  responses  are 
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Two  serv. 
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7,850 

820 

0 

8,720 
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59min 

311,808 

Table  1:  Statistics  for  different  key  generation  methods  (1024  bit  keys) 


instantaneous  compared  to  the  Pilot’s  processing  time.  Consequently,  improving  server  performance 
will  only  marginally  affect  the  overall  running  time. 

5.2.1  Generating  a  1024  bit  key 

Table  1  shows  detailed  timing  measurements  for  generating  1024  bit  RSA  keys.  Our  breakdown  of 
timing  measurements  follows  the  description  in  Section  2.1.  The  first  column  shows  the  time  to  pick  a 
probable  prime,  the  second  shows  the  time  the  Pilot  spent  waiting  for  the  server  to  respond,  the  third 
shows  the  time  to  exponentiate  on  the  PalmPilot  (not  used  in  the  two-server  mode).  The  last  column 
shows  the  total  network  traffic  (in  bytes). 

The  first  two  rows  in  Table  1  measure  the  time  to  generate  keys  on  the  Pilot.  The  first  column 
represents  the  time  to  generate  an  unbalanced  key,  the  second  represents  the  time  to  generate  a  normal 
N  =  pq  key.  Since  an  unbalanced  key  requires  only  one  prime  (the  other  is  a  random  number)  the 
number  of  iterations  for  locally  generating  an  unbalanced  key  is  half  that  for  generating  a  normal  key. 

When  comparing  the  time  per  iteration  for  local  generation  and  two  server  generation,  we  see  that 
using  two  servers  we  get  an  improvement  of  a  factor  of  5.  Using  one  server  we  obtain  an  improvement 
of  a  factor  of  2.  The  average  number  of  iterations  is  approximately  the  same  in  all  three  methods. 
Note  that  the  improvements  are  a  result  of  speeding  up  (or  eliminating)  the  exponentiation  step  on 
the  PalmPilot.  Observe  that  when  two  servers  are  used  the  bottleneck  is  the  sieving  time  —  the  time 
to  generate  a  probable  prime  p. 

On  average,  406  iterations  are  needed  to  generate  a  normal  RSA  key  ( N  =  pq)  with  the  aid  of  two 
servers.  The  large  number  of  iterations  is  a  result  of  the  quadratic  slowdown  discussed  in  Section  4. 
Even  though  each  iteration  is  much  faster  than  the  corresponding  value  for  local  generation,  we  end 
up  hurting  the  total  generation  time. 

Our  algorithms  require  only  a  few  kilobytes  of  data  transfer  between  the  Pilot  and  the  servers. 
The  traffic  generated  is  linear  in  the  number  of  iterations  which  explains  the  large  figure  for  two  server 
normal  key  generation. 

5.2.2  Generating  various  key  sizes 

From  Table  2  we  see  that  the  total  iteration  time  increases  almost  linearly  with  key  size  for  dual  server 
aided  generation.  Indeed,  the  dominant  component  of  each  iteration  is  sieving,  which  takes  linear  time 
as  a  function  of  the  key  size.  The  expected  total  time  for  generating  the  key  is  the  product  of  the 
time-per-iteration  and  the  expected-number-of-iterations. 

Observe  that  the  improvement  over  local  generation  is  less  significant  for  shorter  keys  than  for 
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Table  2:  Statistics  for  different  key  sizes 


longer  keys.  For  instance,  for  a  512  bit  key,  two  servers  improve  performance  by  only  50%.  For  a  1024 
bit  key  the  improvement  is  a  factor  of  5.  The  reason  is  that  for  smaller  keys,  the  primality  test  is  less 
of  a  dominating  factor  in  the  running  time  per  iteration  (we  use  the  same  size  sieve,  2048  primes,  for 
all  key  sizes) .  Hence,  reducing  the  exponentiation  time  has  less  of  an  effect  on  the  the  total  time  per 
iteration. 


6  Conclusions 

At  the  present  using  RSA  on  a  low  power  handheld  is  problematic.  In  this  paper  we  study  whether 
RSA’s  performance  can  be  improved  without  a  loss  of  security.  In  particular,  we  ask  whether  an 
untrusted  server  can  aid  in  RSA  key  generation.  We  wish  to  offload  most  of  the  work  to  the  server 
without  leaking  any  of  the  handheld’s  secrets. 

We  showed  a  significant  improvement  in  the  time  it  takes  to  generate  an  unbalanced  RSA  key. 
With  the  help  of  two  isolated  servers  we  obtained  a  speed  up  of  a  factor  of  5.  With  the  help  of  a  single 
server  we  obtained  a  speed  up  of  a  factor  of  2.  For  normal  RSA  keys,  N  =  pq ,  we  cannot  improve  the 
running  time  due  do  the  quadratic  slowdown  problem  discussed  in  Section  4.  It  is  an  open  problem  to 
speed  up  the  generation  of  a  normal  RSA  key  using  a  single  server.  In  all  our  algorithms  the  load  on 
the  server  is  minimal;  our  experiments  show  that  even  though  the  server  is  doing  most  of  the  work, 
the  PalmPilot  does  not  produce  candidates  fast  enough  to  fully  occupy  the  server.  Our  code  available 
for  anyone  wishing  to  experiment  with  it. 
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Abstract 

Non-repudiation  is  one  of  the  most  important  security  services.  In  this  paper  we  present  a  novel  non¬ 
repudiation  technique,  called  Server-Supported  Signatures,  S3.  It  is  based  on  one-way  hash  functions 
and  traditional,  digital  signatures.  One  of  its  highlights  is  that  for  ordinary  users  the  use  of  asymmetric 
cryptography  is  limited  to  signature  verification.  S3  is  efficient  in  terms  of  computational,  communication 
and  storage  costs.  It  also  offers  a  degree  of  security  comparable  to  that  of  existing  techniques  based  on 
asymmetric  cryptography. 
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1  Introduction 


Computers  and  communication  networks  have  become  an  integral  part  of  many  people’s  daily  lives.  Systems 
to  facilitate  commercial  and  other  transactions  have  been  built  on  top  of  large  open  computer  networks.  These 
transactions  must  often  have  some  legal  significance  if  they  are  to  be  useful  in  real  life.  Non-repudiation  is 
one  of  the  essential  services  necessary  for  attaching  legal  significance  to  transactions  and  information  transfer 
in  general. 

Existing  techniques  for  non-repudiation  are  based  primarily  on  either  symmetric  or  asymmetric  crypto¬ 
graphy.  Practically  secure  symmetric  techniques  are  computationally  more  efficient  but  require  unconditional 
trust  in  third  parties.  “Unconditional”  means  that  if  such  a  third  party  cheats,  the  victim  cannot  prove  this 
to  an  arbiter  (e.g.,  a  court).  Practically  secure  asymmetric  techniques  (which  we  refer  to  as  “traditional 
digital  signatures”  )  are  computationally  less  efficient  but  can  be  constructed  in  a  way  that  allows  one  to 
prove  cheating  by  any  third  parties  involved.  We  call  a  third  party  whose  cheating  can  be  proven  to  an 
arbiter  a  verifiable  third  party. 

We  present  a  novel  non-repudiation  technique  called  Server- Supported  Signatures,  S3.  It  is  based 
on  one-way  hash  functions  and  traditional  digital  signatures.  Like  well-constructed  asymmetric  techniques, 
S3  uses  only  verifiable  third  parties.  However,  for  ordinary  users,  S3  limits  the  use  of  asymmetric  crypto¬ 
graphic  techniques  to  signature  verification.  All  signature  generations  are  done  by  third  parties,  called 
signature  servers.  For  some  signature  schemes,  e.g.,  RSA  with  a  public  exponent  of  3,  verifying  signatures 
is  significantly  more  efficient  than  generating  them. 

2  Background  and  Motivation 

The  International  Standardization  Organization  (ISO)  is  in  the  process  of  standardizing  techniques  to  provide 
non-repudiation  services  in  open  networks.  Current  versions  of  the  draft  ISO  standards  [5]  identify  various 
classes  of  non-repudiation  services.  Two  of  these  are  of  particular  interest: 

•  Non-repudiation  of  Origin  (NRO)  guarantees  that  the  originator  of  a  message  cannot  later  deny 
having  originated  that  message. 

•  Non-repudiation  of  Receipt  (NRR)1  guarantees  that  the  recipient  of  a  message  cannot  deny  having 
received  that  message. 

Non-repudiation  for  a  particular  message  is  obtained  by  constructing  a  non-repudiation  token.  The 
non-repudiation  token  must  be  such  that  it  can  be  verified  by: 

•  the  intended  recipients  of  the  token  (e.g.,  in  the  case  of  NRO,  the  recipient  of  the  message;  in  the  case 
of  NRR,  the  originator  of  the  message),  and 

•  in  case  of  a  dispute,  by  a  mutually  acceptable  arbiter. 

The  draft  ISO  standards  divide  non-repudiation  techniques  into  two  classes: 

•  Asymmetric  non-repudiation  techniques  are  based  on  digital  signature  schemes  using  public-key  crypto¬ 
graphy.  The  main  (and  probably  the  only)  difficulty  in  using  digital  signature  schemes  is  the  compu¬ 
tational  cost  involved.  This  is  a  particularly  serious  issue  when  “anemic”  portable  devices  (like  mobile 
phones)  are  involved. 

Non-repudiation  is  based  on  certification  of  the  signer’s  public  key  by  a  certification  authority.  Trust  in 
this  certification  authority  can  be  minimized  by  an  appropriate  registration  procedure.  For  example,  the 
signer  and  the  authority  may  be  required  to  sign  a  paper  contract  listing  the  signer’s  and  certification 
authority’s  public  keys,  responsibilities,  and  liabilities,  possibly  in  front  of  a  notary  public.  In  the 
worst  case,  the  certification  authority  could  cheat  the  user  by  issuing  a  certificate  with  a  public  key 

1ISO  documents  call  this  “non-repudiation  of  delivery  (NRD).”  We  use  the  term  “receipt”  because  we  feel  that  the  term 
“delivery”  is  more  appropriate  to  describe  the  function  performed  by  the  message  transport  system. 
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chosen  by  a  cheater.  But  the  supposed  signer  could  deny  all  signatures  based  on  this  forged  certificate 
by  citing  the  contract  signed  during  registration.  Thus,  trust  is  reduced  to  trust  in  the  verifiability  of 
the  registration  procedure. 

•  Symmetric  non-repudiation  techniques  are  based  on  symmetric  message  authentication  codes  (MACs) 
and  trusted  third  parties  that  act  as  witnesses.  Generating  and  verifying  message  authentication  codes 
are  typically  low-cost  operations  compared  to  digital  signature  operations. 

The  signer  has  to  trust  the  third  party  unconditionally,  which  means  that  the  third  party  could  cheat  the 
user  without  giving  the  user  any  chance  to  deny  forged  messages.  One  could  reduce  this  trust  by  using 
several  third  parties  in  parallel  or  by  putting  the  third  party  into  tamper  resistant  hardware.  These 
two  approaches  increase  both  cost  and  complexity  but  neither  of  them  solves  the  problem  completely. 

In  the  following  we  present  a  new,  low-cost  technique  for  non-repudiation  services,  called  server-supported 
signatures.  It  uses  both  traditional  digital  signatures  (based  on  asymmetric  cryptographic  techniques)  and 
one-way  hash  functions  in  order  to  minimize  the  computational  costs  for  ordinary  users.  Our  main  motivation 
arises  from  the  typical  mobile  computing  environments  where  the  mobile  entities  have  considerably  less 
computing  power  than  do  static  entities. 

3  Server-Supported  Signatures  for  Non-repudiation  of  Origin 

3.1  Preliminaries:  One-way  Hash  Functions 

Intuitively,  a  one-way  function  /()  is  a  function  such  that  given  an  input  string  x  it  is  easy  to  compute  f(x), 
but  given  a  randomly  chosen  y  it  is  computationally  infeasible  to  find  an  x'  such  that  f(x')  =  y.  A  one-way 
hash  function  is  a  one-way  function  hQ  that  operates  on  arbitrary-length  inputs  to  produce  a  fixed  length 
value.  The  term  x  is  called  a  pre-image  of  h(x).  A  one-way  hash  function  hQ  is  said  to  be  collision-resistant 
if  it  is  computationally  infeasible  to  find  any  two  strings  x  and  x'  such  that  h(x )  =  h(x').  Collision-resistance 
implies  one-wayness  [13,  Section  7.2].  A  number  of  efficient  and  allegedly  one-way  hash  functions,  such  as 
SHA[8],  have  been  invented.  One-way  hash  functions  can  be  recursively  applied  to  an  input  string.  The 
notation  h’ (x)  denotes  the  result  of  applying  hQ  i  times  recursively  to  an  input  x.  That  is, 

hl(x)  =  h(h(h(. .  .  h(x)  . . .))) 

S - v - ' 

i  times 

Such  recursive  application  results  in  a  hash-chain  that  is  generated  from  the  original  input  string: 

h°(x)  —  x,  hl(x), . . . ,  hn(x) 


3.2  Model  and  Notation 

We  distinguish  three  types  of  entities  in  the  system: 

•  Users  -  participants  in  the  system  who  wish  to  avail  themselves  of  the  non-repudiation  service  while 
sending  and  receiving  messages  among  themselves. 

•  Signature  Servers  -  special  entities  responsible  for  actually  generating  the  non-repudiation  tokens  on 
behalf  of  the  users. 

•  Certification  Authorities  -  special  entities  responsible  for  linking  public  keys  with  identities  of  users 
and  servers. 

Signature  servers  and  certification  authorities  will  be  verifiable  third  parties  from  the  users’  point  of  view. 

All  entities  agree  on  a  one-way,  collision-resistant  hash-function  hQ  and  a  digital  signature  scheme. 
Entities  should  “personalise”  the  hash  function.  For  example,  this  can  be  done  by  always  including  their 
unique  name  as  an  argument:  using  h(0,x),  where  O  is  the  entity  computing  the  one-way  hash.  We  use 
hoQ  to  refer  to  the  personalised  hash  function  used  by  O. 
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The  result  of  digitally  signing  a  message  x  with  signature  key  SK  is  denoted  by  (x)SK .  We  also  assume 
that,  given  (x)SK ,  anyone  can  extract  x  from  it  provided  they  have  the  public  key  corresponding  to  SK . 
The  users’  security  depends  on  the  one-way  property  of  ho (),  which  must  hold  even  against  the  servers. 
In  practice,  this  is  not  a  problem  because  hash  functions  such  as  SHA  are  one-way  for  all  parties.  We 
note,  however,  that  so-called  cryptographically  strong  hash-functions  are  usually  invertible  for  the  party 
that  generated  the  hash-function. 

In  order  to  minimize  the  computational  overhead  for  users,  ho()  must  be  efficiently  computable,  and 
digital  signatures  must  be  efficiently  verifiable.  Only  signature  servers  and  certification  authorities  need  to 
have  the  ability  to  generate  signatures.  SHA  as  hash  function  and  RSA  with  public  exponent  3  as  signature 
scheme  would  be  reasonable  choices. 

Each  user,  O  ( O  as  in  Originator)  generates  a  secret  key,  A'o,  randomly  chosen  from  the  range  of  ho(). 
Based  on  A'o,  user  O  computes  the  hash  chain  A'q,  A'q,  . . .  Kq,  where 

K°o  =  K0,  K’o  =  Wo)  =  M K'J1} 

PKo  =  Kq  constitutes  O’s  root  public  key.  Root  public  key  Kq  will  enable  O  to  authenticate  n  messages. 
This  is  not  a  limitation:  before  the  old  root  public  key  is  consumed  completely  a  new  root  public  key  can 
be  generated  and  authenticated  using  the  old  root  public  key. 

Each  signature  server  S  generates  a  pair  of  secret  and  public  keys  (SKs ,  PKs)  of  the  digital  signature 
scheme.  Each  certification  authority,  CA,  does  the  same.  The  CA  is  responsible  for  verifiably  binding  a  user 
O  (server  S)  to  her  root  public  key  PKo  (its  public  key  PKs).  We  assume  that  the  registration  procedure 
is  constructed  such  that  CA  becomes  a  verifiable  third  party. 


Notation  Summary 

h0  ()  -  one-way  collision-resistant  hash  function  for  O 
SKx  -  secret  key  known  only  to  entity  X 
Kq  -  user  O’s  ( n  —  i)-th  public  key 
( x)SK  -  digital  signature  on  message  x  with  secret  key  SK 
[?7i]  -  Message  m  sent  via  a  confidential  channel 


3.3  Initialization 

To  participate  in  the  system,  a  user  O  chooses  a  signature  server  S  that  shall  be  responsible  for  generating 
signatures  on  O’s  behalf,  generates  a  random  secret  key  A'o,  and  constructs  the  hash  chain.  As  will  be 
described  below,  O  can  cause  S  to  transfer  the  signature  generation  responsibility  to  another  signature 
server  S' ,  if  required  (e.g.,  because  O  is  a  mobile  user  who  wishes  to  always  use  the  closest  server  available). 

O  submits  the  root  public  key  PKo  =  Kq  to  a  CA  for  certification.  A  certificate  for  O’s  root  public  key 
is  of  the  form 

Cert0  =  (O,  ii.  PK0 ,  S)SKCa 

We  ignore  all  information  typically  contained  in  a  certificate  but  not  relevant  to  the  discussion  at  hand,  e.g. 
organizational  data  such  as  serial  numbers  and  expiration  dates.  The  registration  performed  by  O  and  CA 
must  be  verifiable,  as  discussed  above.  CA  may  make  the  certificate  available  to  anyone  via  a  directory 
service.  O  then  deposits  the  certificate  received  from  CA  with  S. 

Each  signature  server  S  acquires  a  certificate  containing  PKs  from  its  CA.  As  these  are  ordinary  public 
key  certificates,  we  do  not  describe  them  here. 

For  the  sake  of  simplicity,  we  do  not  include  the  certificates  in  the  following  protocols.  They  might  be 
attached  to  other  messages  or  retrieved  using  a  directory  service.  We  assume  that  the  necessary  certificates 
are  always  available  to  anyone  who  needs  to  verify  a  signature. 

3.4  Generating  NRO  Tokens 

The  basic  idea  is  to  exploit  the  digital  signature  generation  capability  of  a  signature  server  to  provide  non¬ 
repudiation  services  to  ordinary  users.  The  basic  protocol,  providing  non-repudiation  of  origin,  is  illustrated 
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in  Figure  1.  We  assume  that  a  user  O  wants  to  send  a  message  m  along  with  an  NRO  token  to  some  recipient 
R.  The  first  protocol  run  uses  i  —  n;  i  is  decreased  during  each  run. 

1.  O  begins  by  sending  ( 0,m,i )  to  its  signature  server  S  along  with  O’ s  current  public  key  K’0  in  the 
first  protocol  flow  (in  case  O  does  not  want  to  reveal  the  message  to  S  for  privacy  reasons,  m  can  be 
replaced  by  a  randomised  hash  of  m,  computed  using  a  collision-resistant  hash  function). 

2.  S  verifies  the  received  public  key  based  on  O’s  root  public  key  (and  O’s  certificate  obtained  from  CA), 
i.e.,  checks  that  I)q  '(Kq)  =  PKo-  The  signature  server  S  has  to  ensure  that  only  one  NRO  can  be 
created  for  a  given  (0,?,/1q).  If  a  message  on  behalf  of  O  containing  K'()  has  not  yet  been  signed, 
S  signs  (0,m,i,  Kl0),  records  K’Q  as  consumed,  and  sends  the  signature  (which  we  call  the  candidate 
non-repudiation  token)  back  to  O  in  the  second  flow. 

3.  O  verifies  the  received  signature  and  records  K'0  as  consumed  by  replacing  i  by  i  —  1.  The  NRO  token 
for  R  now  consists  of 


(O ,  m,,  i,  Kq)SKs  ,  Kz0  1 

O  produces  this  token  which  actually  authenticates  m.  by  revealing  K’(J  1 . 

In  Figure  1  we  assumed  that  the  NRO  token  is  sent  to  R  via  S  in  the  third  flow.  Alternatively,  O  can 
send  the  token  directly  to  R. 


Figure  1:  Protocol  providing  non-repudiation  of  origin. 

Kq  is  referred  as  the  token  public  key  of  the  (n— i+l)th  non-repudiation  token,  (O,  in.  i,  Kq)SKs ,  A^-1. 
Note  that  O  must  consume  the  token  public  keys  in  sequence  and  must  not  skip  any  of  them.  In  particular, 
O  must  not  ask  for  a  signature  using  IPq1  as  token  public  key  unless  she  has  received  S’ s  signature  under 
Kq:  Otherwise,  S  could  use  that  to  create  a  fake  non-repudiation  token,  which  O  cannot  repudiate  during 
a  dispute. 

3.5  Dispute  Resolution 

In  case  of  a  dispute,  R  can  submit  the  NRO  to  an  arbiter.  The  arbiter  will  verify  the  following: 

•  the  public  keys  are  certified  by  CA, 

•  the  signature  in  the  token  by  the  signature  server  is  valid, 

•  the  token  public  key  is  in  fact  a  hash  of  the  alleged  pre-image  in  the  token,  and 

•  the  root  public  key  can  be  derived  from  the  token  public  key  by  repeated  hashing. 
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If  these  checks  are  successful,  then  the  originator  is  allowed  the  opportunity  to  repudiate  the  token  by 

•  proving  that  CA  cheated: 

—  If  O  has  registered  with  CA,  O  can  show  a  certificate  on  a  different  root  public  key. 

—  Otherwise  CA  will  be  asked  to  prove  that  the  root  public  key  was  registered  by  O  (i.e. ,  by  showing 
the  signed  contract  with  O). 

•  proving  that  S  cheated  by  showing  a  different  non-repudiation  token  corresponding  to  the  same  token 
public  key. 

Note  that  in  case  CA  is  honest,  to  claim  falsely  that  O  has  sent  a  message  m1 ,  a  cheating  R  has  to 
produce  an  NRO  token  of  the  form: 


(O ,  m! ,  i,  Kq)SKs  ,  Kq  1 

If  O  has  not  revealed  Kff1  yet,  then  one-wayness  of  ho()  implies  that  anyone  else  will  find  it  computa¬ 
tionally  infeasible  to  generate  this  NRO  token,  even  if  K’0  is  known.  If  O  has  already  revealed  K’q1  she  must 
have  sent  K’0  to  S  before.  According  to  the  protocol,  O  reveals  K’q1  only  if  she  has  received  a  signature 
from  S  under  K’0  which  satisfied  her.  Therefore,  O  can  show  a  different  token  corresponding  to  the  same 
token  public  key. 

Suppose  an  adversary  of  O  successfully  breaks  the  one-wayness  of  ho()  and  obtains  an  NRO  token  of  the 
form: 

(O,  m! ,  i,  Kq)SKs,x 

where  ho{x )  —  ho{KlQl>}.  If  x  is  different  from  K’q1,  then  on  being  challenged  with  this  NRO  token,  O  can 
reveal  K’q1,  proving  that  the  system  has  been  broken.  This  is  known  as  the  “fail-stop”  property.  Assuming 
that  ho  has  a  uniform  distribution,  the  domain  used  must  be  larger  than  the  range  of  ho  in  order  to  achieve  a 
reasonable  level  of  fail-stop  property.  We  can  do  this  by  slightly  modifying  the  building  procedure  to  include 
a  random  padding  to  the  input  of  ho  during  the  computation  of  every  link  in  the  chain.  The  sequence  of 
random  pads  used  are  generated  using  a  pseudo-random  number  generator  whose  seed  is  committed  to  in 
the  certificate. 


4  Server-Supported  Signatures  for  Non-repudiation  of  Origin 
and  Receipt 

Non-repudiation  of  receipt  (NRR)  can  be  easily  added  to  the  basic  protocol.  Before  sending  Kff 1  to  R,  S 
can  ask  R  for  an  NRO  token  for  “NRR”|m,  which  is  then  passed  on  to  O.  This  is  illustrated  in  Figure  2. 
The  NRR  token  consists  of: 


{R,  “NRR”  | m,  j,  K3r)SKs  ,  Kj~ 1 ,  r 

Square  parentheses  ([  ])  indicate  that  the  message  contained  within  them  is  sent  via  a  confidential  channel. 
As  this  protocol  is  just  two  interleaved  instances  of  the  basic  NRO  protocol,  it  still  guarantees  that  O  and 
R  can  repudiate  all  forged  NRO  and  NRR  tokens,  respectively.  Note  that  this  protocol  actually  implements 
fair-exchange  of  the  NRO  token  for  m  and  its  NRR  token,  based  on  S'  as  a  trusted  third  party.  If  S  behaves 
dishonestly,  no  fairness  can  be  guaranteed:  O  might  not  receive  the  NRR  token  or  R  might  not  receive  the 
NRO  token. 

The  protocol  as  depicted  in  Figure  2  allows  the  possibility  that  R  may  refuse  to  send  the  NRR  token  after 
having  received  the  candidate  NRR  token  from  S  (from  which  R  can  extract  m).  An  alternative  approach  is 
to  include  only  a  commitment  to  the  message  m  in  the  candidate  NRO  token  instead  of  the  actual  message 
itself.  However,  R  has  to  trust  that  S  will  in  fact,  send  m  after  R  has  already  acknowledged  having  received 
it.  Note  that  if  O  and  R  happen  to  use  different  signature  servers,  additional  inter-server  message  flows  will 
be  necessary. 


113 


0  s 

R 

0,  rn .  i ,  Kq,  R 

( 0 ,  m,  i,  K’0)SKs 

(R,  “NRR”  \m,  j,  KfySKs 

[Kr1] 

( R ,  “NRR”  |m,  j,  Kjr)SKs 

Kb'1 

( 0 ,  m ,  i,  K’0)SKs ,  K’q  1 

Figure  2:  Protocol  providing  non-repudiation  of  origin  and  receipt. 


Figure  3:  Protocol  providing  integrated  non-repudiation  of  origin  and  receipt. 


This  protocol  allows  the  possibility  that  either  the  NRO  token  or  the  NRR  token  may  be  optional,  at 
the  cost  of  an  extra  signature  by  S.  The  entire  protocol  has  eight  message  flows.  Further,  the  NRO  and 
NRR  tokens  are  linked  only  by  the  hash  of  the  message.  In  environments  where  both  NRO  and  NRR  are 
mandatory,  a  modified  protocol  as  shown  in  Figure  3  can  be  used.  It  results  in  a  combined  NRO  and  NRR 
token : 

(O,  “NRX”  |m,  i,  j,  Ki,  K3r)SK&;K'J%  l<i 

The  modified  protocol  has  only  seven  message  flows  and  requires  only  a  single  signature  by  S. 

5  Variations  on  the  Theme 

5.1  Reducing  Storage  Requirements  for  Users 

In  order  to  deny  forged  non-repudiation  tokens,  O  has  to  store  all  signatures  received  from  S,  which  might 
be  a  bit  unrealistic  for  a  device  that  is  not  even  able  to  compute  signatures.  One  can  easily  avoid  this  storage 
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problem  by  including  an  additional  field  H  in  S’s  signature  that  serves  as  a  commitment  on  all  the  previous 
signatures  made  by  S  for  that  hash  chain;  i.e.,  an  NRO  token  looks  like 

NR&  :=  ((O,  rm,i,  K}>,  H^SKg ,  K^1) 

The  value  H'  is  recursively  computed  by  Hn  :=  Certo  and  H’~l  :=  f(H\  NRO1).  The  function  /()  is 
a  collision-resistant  one-way  hash  function2.  NRO ’  is  an  NRO  token  on  message  rti,;  using  the  token  public 

key  Kq. 

O  has  to  store  only  the  last  value  H 1  and  the  last  signature  received  from  S.  S  has  to  store  all  signatures, 
and  has  to  provide  them  to  O  in  case  of  a  dispute.  If  S  cannot  provide  a  sequence  of  signatures  that  fits 
the  hash  value  contained  in  the  last  signature  received  by  O,  the  arbiter  allows  O  to  repudiate  all  signatures 
and  assumes  that  S  cheated. 

This  idea  of  chaining  previous  signatures  was  used  by  Haber  and  Stornetta  [3]  for  the  construction  of 
a  time  stamping  service,  based  on  the  observation  that  the  sequence  of  messages  in  H’  cannot  be  changed 
afterwards.  One  can  combine  their  protocols  with  ours,  using  S'  as  a  time  stamping  server,  as  explained  in 
Section  6.1. 

5.2  Increasing  Robustness 

As  mentioned  above,  a  signature  server  must  sign  exactly  one  message  for  a  given  user  per  public  key  ( K’0 )  in 
the  hash  chain.  However,  anyone  can  send  a  signature  request  in  the  form  of  the  first  flow,  i.e.,  (O ,  m ,  i,  K’Q ). 

If  the  signature  server  does  not  subsequently  receive  the  corresponding  pre-image  of  the  current  public 
key  (A'q-1),  the  current  public  key  is  rendered  invalid  in  any  case.  This  implies  that  an  attacker  can  succeed 
in  invalidating  an  entire  chain  of  a  user  by  generating  fake  signature  requests  in  her  name. 

An  obvious  solution  would  be  to  require  O  and  S  to  share  a  secret  key  to  be  used  for  computing  (and 
verifying)  a  message  authentication  code  over  the  first  protocol  flow. 

An  alternative  solution  is  to  give  users  the  ability  to  invalidate  token  public  keys  without  having  to 
create  a  new  chain.  The  construction  is  only  slightly  more  complicated  than  the  basic  protocol:  instead  of 
one  chain,  each  user  generates  two  chains  (computed  with  two  different  hash  functions):  Kq , . . .  ,Kq  and 

f<n  k° 

J\q,  .  .  . ,  1\q. 

Each  token  public  key  is  now  a  pair  of  hash  values,  say,  (Kq,  Kq).  If  O  receives  the  candidate  token 
(O,  m,  i,K’o,  Kq)SKs  ,  she  can  either  accept  or  reject  it; 

•  O  accepts  by  revealing  K’q1.  The  next  token  public  key  is  (K’q1  ,Kq). 

•  O  rejects  by  revealing  Aq_1.  The  next  token  public  key  is  (K’Q,  K^1). 

On  receiving  K’q1  or  KJ0  ,  server  S  creates 

•  the  non-repudiation  token  ( 0,m,i,j,KJo,K,Q1)SKs  or 

•  the  invalidation  token  (O,  “INV”  \m,  i,  j,  K’Q ,  A  )S  l\  s 
respectively. 

The  additional  signature  by  S  is  necessary  because  for  one  signature 

(O,  m,  i,  j,  Kq,  Kq)SKs 

it  can  easily  happen  that  both  K’q1  and  K 30~1  become  public,  i.e.,  the  combination  of  the  first  signature  with 
one  pre-image  would  not  be  unambiguous  and  recipient  R  could  not  depend  on  what  he  receives.  Instead 
of  making  two  signatures,  S  can  instead  include  two  commitments  h(apiRo)  and  h(ajNv)  of  two  random 
numbers  onro  and  a/jvv  in  the  first  signatures.  Then,  S  can  release  one  of  the  two  random  numbers  to 
O.  The  random  number  together  with  the  first  signature  serves  as  either  the  NRO  token  or  the  invalidation 
token.  Note  that  a  cheating  S  could  generate  both  tokens  for  the  same  token  public  key,  but  O  could  easily 
prove  that  S  cheated  by  showing  the  token  received. 

2  Note  that  /()  may  be  the  same  as  t  ( ,  ( ) .  However,  collision-resistance  is  a  mandatory  property  for  /( )  (if  S  succeeds  in 
breaking  the  collision-resistance  of  /(),  it  can  forge  signatures  which  O  may  not  be  able  to  refute  since  O  no  longer  retains  all 
past  signatures).  As  we  mentioned  in  Section  3.5,  collisions  in  /io()  are  no*  equally  catastrophic  from  the  point-of-view  of  O. 
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5.3  Support  for  Roaming  Users 

In  the  basic  protocol,  the  trust  placed  on  the  signature  server  is  quite  limited  —  it  is  trusted  only  to  protect 
its  secret  key  from  intruders  and  to  generate  signatures  in  a  secure  manner.  This  limited  trust  enables  a 
mobile  user  to  make  use  of  a  signature  server  in  foreign  domains  while  travelling.  Normally  the  signature 
server  in  the  user’s  home  domain  will  be  in  charge  of  the  user’s  hash  chain.  Whenever  the  user  requests  to 
be  transferred  to  a  signature  server  in  a  different  domain,  an  agreement  could  be  signed  by  the  user  and  the 
old  signature  server  authorising  the  transfer  of  charge  of  the  user’s  hash  chain.  As  usual,  the  pre-image  of 
the  current  token  public  key,  used  to  sign  this  agreement  will  become  the  next  token  public  key. 

In  other  words,  instead  of  having  a  single  root  public  key  certificate  (which  includes  the  identity  of  the 
“home”  signature  server),  a  chain  of  public  key  certificates  could  be  used.  The  chain  consists  of  the  root 
public  key  certificate  signed  by  the  home  CA  and  one  hand-off  certificate  every  time  the  charge  for  the  user’s 
public  key  has  changed  hands: 

(0, 7i,  Kq,  So)SKCa 

(O,  m,  Kq1  ,  Si)SKSl_1 ,  for  0  <  //,■  <  n.l  >  0 

where,  So  =  S  and  nj  is  the  index  of  the  token  public  key  used  to  sign  the  request  for  the  Ith  hand-off  (from 
Si-i  to  S,). 

To  effect  a  change  in  charge  during  a  handoff,  the  following  procedure  is  carried  out: 

1.  The  user  O  sends  a  hand-off  request  to  both  the  current  signature  server  Si- 1  and  the  intended 
signature  server  Si.  As  this  request  must  be  non-repudiable,  this  step  is  essentially  a  run  of  the  basic 
protocol  to  generate  a  NRO  token  with  a  message  that  means  “hand-off  from  Si- 1  to  Si  requested.” 
Si— i  will  issue  a  candidate  NRO  token  for  the  request  using  the  current  token  public  key  Kq1  and  O 
will  validate  the  token  by  revealing  Kq  ~ 1 ) . 

2.  When  the  NRO  token  is  received  and  verified  by  Si- i,  it  generates  a  corresponding  hand-off  certificate 
described  in  the  previous  paragraph  and  sends  it  to  both  O  and  Si.  It  will  no  longer  generate  signatures 
on  behalf  of  O  for  that  hash  chain  unless  charge  is  explicitly  transferred  back  to  it  at  some  point.  In 
addition,  it  will  store  both  the  hand-off  certificate  and  the  corresponding  NRO  token. 

3.  When  Si  has  received  both  the  NRO  token  and  the  hand-off  certificate,  it  will  be  ready  to  generate 
signatures  on  behalf  of  O,  starting  with  Kq  ~  1  as  the  first  token  public  key. 

5.4  Key  Revocation 

As  with  any  certificate-based  system,  there  must  be  a  way  for  any  user  O  to  revoke  her  hash  chain.3  If  the 
currently  secret  portion  of  O’ s  hash  chain  (say  Kq,  for  i  —  p  —  l,p  —  2, . . .  1)  has  been  compromised,  O  will 
detect  this  when  she  attempts  to  construct  an  NRO  the  next  time  for  the  token  public  key  Kq:  S  will  return 
an  error  indicating  the  current  token  public  key  Kq(q  <  p)  from  S’ s  point  of  view.  O  can  attempt  to  limit 
the  damage  by  doing  one  of  the  following: 

1.  invalidate  all  remaining  token  public  keys  K’0(i  —  q,q  —  1, . .  .1)  by  requesting  NRO  tokens  for  them, 
or 

2.  notifying  S  to  invalidate  the  remaining  hash  chain  by  sending  it  a  non-repudiable  request  to  that  effect 
and  receiving  a  non-repudiable  statement  from  S  stating  that  the  hash  chain  has  been  invalidated. 
This  can  be  implemented  similar  to  the  invalidation  tokens  described  in  Section  5.2  —  except  in  this 
case  the  token  would  invalidate  the  entire  chain  and  not  just  a  single  key. 

3  Revocation  by  authorities  is  not  an  issue  in  this  system  because  the  user  has  to  interact  with  the  signature  server  for  the 
generation  of  every  new  NR  token  anyway. 
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5.5  General  Signature  Translation 

In  a  more  general  light,  the  signature  server  in  S3  can  be  viewed  as  a  “translator”  of  signatures:  it  translates 
one-time  signatures  based  on  hash-functions  into  traditional  digital  signatures.  The  same  approach  can  be 
used  to  combine  other  techniques  such  that  the  result  provides  some  features  that  are  not  available  from  the 
constituent  techniques  by  themselves. 

For  example,  one  could  select  a  traditional  digital  signature  scheme  (say  D\)  where  signing  is  easier  than 
Verification  (e.g.  DSS)  and  one  (say  D 2)  where  verification  is  easier  than  signing  (e.g.  RSA  with  a  low  public 
exponent)  and  construct  a  similar  composite  signature  scheme.  The  signature  key  of  an  entity  X  in  digital 
signature  scheme  D  is  denoted  by  SK® .  To  sign  a  message  m,  an  originator  O  would  compute  ( m)SKQ 1 
and  pass  it  along  with  m  to  the  signature  server  S.  If  the  server  can  verify  the  signature,  it  will  translate  it 
to  (m,(m)SK^1)SKg  ^,  In  other  words,  the  composite  scheme  allows  digital  signatures  where  both  signing 
and  verification  are  computationally  inexpensive. 


6  Applications 

6.1  Building  a  Secure  time  stamping  Service 

In  Section  3.5,  we  argued  that  S3  meets  the  standard  requirements  of  a  signature  scheme.  The  structure  of 
the  non-repudiation  tokens  result  in  an  additional  property:  non-repudiation  tokens  issued  by  a  given  user 
have  a  strict  temporal  ordering  among  them. 

Recall  the  structure  of  the  non-repudiation  tokens  described  in  Section  5.1: 

NRO  :=  ((O,  nn,i,  KiQ,Hi ) SKs ,  K’ff 1 ) 


where , 

Hn  :=  A'g,  FT”1  =  fill'.  X HO  ) 

If  /()  is  collision-resistant,  the  chaining  factor  //'  imposes  an  order  among  the  messages  signed.  We  call  this 
a  token  chain.  Suppose  that 

{NRO1},  i  =  n - p,p  —  1  . .  .q 

indicates  the  token  chain  of  (NRO  tokens  issued  by)  a  certain  user  O  at  a  given  time.  It  is  easy  to  see  that 
all  NR09,q  <  p,  must  have  been  created  after  NROp.  As  NRCF  is  a  commitment  on  mp,  it  follows  that 
O  knew  mp  and  showed  it  to  S  before  NRO 9  was  created.  O  and  S,  either  by  themselves  or  in  collusion, 
cannot  create  NROp  after  NRO9  was  created.  This  enables  us  to  build  a  time  stamping  service  based  on  S3. 

Ideally,  a  time  stamping  system  must  be  able  to  impose  a  total  order  on  all  the  messages  time  stamped. 
We  can  adapt  the  approach  used  in  [3],  where  S  generates  a  chaining  factor  from  a  single ,  global  chain.  Every 
signature  generated  by  the  server  has  a  chaining  factor  from  this  global  chain.  To  verify  a  given  time  stamp, 
one  needs  to  know  the  owners  of  the  previous  (and  if  necessary  the  subsequent)  time  stamps  generated  by 
the  time  stamping  server. 

In  Section  4,  we  outlined  a  protocol  that  results  in  a  combined  NRO/NRR  token.  Chaining  factors  can 
be  included  in  this  token  as  well.  The  resulting  NR  token  will  be 


NRab  ~ 


=  {A,  “MIX”  [ni;j ).  i.  j,  I<’A ,  K3b  ,  H’a  ,  H3b)SKs  ,  Ka 


i  —  1 


- 1 


where 

"a  :  •  Ka:  H’a1  —  f(H'A,  NR<jA) 

H9-1  =  f(HiB:NRdB), 

and  NRab  is  the  same  as  NROlA  and  NROib.  Each  time  A  sends  a  message  to  B  using  the  modified  protocol 
resulting  in  a  combined  NRX  token,  the  token  chains  of  A  and  B  are  “synchronised:”  any  NR(fA,p  >  i  must 
have  been  created  before  any  NR09B,q  <  j.  Although  this  does  not  necessarily  result  in  a  total  order,  the 
more  chains  are  synchronised  after  a  message  has  been  signed,  the  greater  the  number  of  witnesses  to  the 
time  of  signing. 
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Thus,  S3  can  be  used  to  temporally  link  the  tokens  generated  by  S  on  behalf  of  multiple  users.  A  practical 
implementation  of  a  time  stamping  service  can  be  constructed  by  requiring  that  S  include  a  time  stamp  in 
each  signature  generated.  The  aim  of  this  construction  is  not  to  provide  an  absolute  guarantee  that  the  time 
stamp  in  a  document  is  precisely  correct.  Instead,  the  temporal  ordering  property  of  S3  signatures  is  used 
to  verify  if  the  time  stamp  is  plausible.  In  case  of  a  dispute  about  the  time  stamp  on  a  signature  by  A,  the 
token  chains  of  all  parties  synchronised  to  T’s  chain  after  the  signature  was  made  are  examined  (suppose 
there  are  n  such  parties).  If  these  token  chains  satisfy  all  the  temporal  ordering  relationships  discussed  above 
and  if  there  is  a  sufficient  number  of  honest  parties  among  those  linked  to  T’s  token  chain,  then  the  time 
stamp  is  probably  correct.  In  this  scenario,  at  least  all  but  one  of  the  n  +  2  parties  involved  must  collude  in 
order  to  produce  a  fake  time  stamp  which  cannot  be  proved  to  be  a  fake. 

When  digital  signatures  are  used  as  a  means  to  provide  accountability,  it  is  crucial  to  have  unforgeable 
time  stamps  embedded  in  the  signatures.  The  usual  technique  to  achieve  this  is  to  use  a  seperate,  external 
time  stamping  service  is  used  in  conjunction  with  a  traditional  digitial  signature  mechanism.  The  structure 
of  S3  makes  it  a  signature  scheme  with  an  integrated  unforgeable  time  stamping  facility. 

6.2  Applications  with  a  Fixed  Recipient 

As  the  role  of  the  signature  server  is  verifiable,  the  recipient  can  also  play  that  role.  This  is  useful  in 
applications  where  several  non-repudiable  messages  need  to  be  sent  to  the  same  fixed  recipient.  An  example 
of  this  is  a  home-banking”  (or  electronic  funds  transfer)  application,  where  customers  send  signed  payment 
orders  to  their  bank. 

Payments  messages  are  of  the  form 


m  =  ( payee ,  amount,  date ) 

When  a  payer  wants  to  make  a  payment,  he  constructs  a  message  of  the  above  form  and  executes  the  normal 
S3  protocol  with  the  bank,  resulting  in  an  NRO  token  for  the  message.  The  bank  then  transfers  amount  to 
the  account  of  payee  and  issues  a  special  NRR  token,  which  can  be  its  signature  on  the  entire  NRO  token. 
Optionally,  it  may  also  get  a  S3  NRR  token  from  the  payee  and  forward  it  to  the  payee.  The  non-repudiation 
tokens  serve  as  evidence  of  the  transaction. 

The  idea  of  using  a  hash  chain  for  repeated,  fixed-value  payments  was  suggested  recently  [9,  4].  We 
have  been  able  to  use  S3  for  payments  of  arbitrary  values  because  S3  provides  non-repudiation  of  origin  for 
arbitrary  messages. 

7  Analysis 

Computation:  Ordinary  users  of  S3  need  to  be  able  to  compute  one-way  hashes  and  to  verify  traditional 
digital  signatures.  Only  the  signature  servers  and  CAs  are  required  to  generate  traditional  digital  signatures. 
Key  generation  for  ordinary  users  is  also  relatively  simple:  the  user  needs  to  be  able  to  generate  a  random 
number.  In  contrast,  key  generation  in  traditional  digital  signature  systems  is  typically  more  complex, 
involving,  for  example,  the  generation  of  large  prime  numbers.  In  summary,  the  computational  requirements 
for  ordinary  users  of  S3  are  less  than  those  using  a  traditional  digital  signature  scheme  offering  comparable 
security. 

Storage:  Using  the  improvement  described  in  Section  5.1,  users  need  to  store  only  the  last  signature 
received  from  S,  the  pre-image  of  the  current  token  public  key  and  the  sequence  number,  and  the  public 
keys  needed  to  verify  certificates. 

Signature  servers  need  to  store  all  generated  signatures  in  order  to  provide  them  to  the  users  on  demand. 
The  stored  signatures  are  necessary  only  in  case  of  a  dispute.  Therefore,  they  can  be  periodically  down-loaded 
to  a  secure  archive. 

Communication:  The  communication  overhead  of  S3  is  comparable  to  that  of  standard  symmetric 
non-repudiation  techniques  because  a  third  party,  S,  is  involved  in  each  generation  of  a  non-repudiation 
token. 

Using  traditional  digital  signatures,  the  involvement  of  third  parties  can  be  restricted  to  exception  han¬ 
dling,  whereas  token  generation  is  usually  lion-interactive.  The  price  to  be  paid  for  this  gain  in  efficiency  is 
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that  revocation  of  signature  keys  becomes  more  complicated.  Note  that  in  S3,  revoking  a  key  is  trivial.  O 
simply  has  to  invalidate  the  current  chain. 

Security:  In  the  preceding  sections,  we  demonstrated  that  as  long  as  the  registration  procedure,  the 
digital  signature  scheme,  and  the  one-way  hash  function  are  secure,  both  users  and  signature  servers  are 
secure  with  respect  to  their  respective  objectives.  Furthermore,  the  security  of  originators  depends  on  the 
strength  of  the  hash  function  and  not  on  the  security  of  the  digital  signature  scheme. 

Additionally,  we  observe  that  in  practice,  traditional  digital  signature  algorithms  are  not  applied  directly 
to  arbitrarily  long  messages.  Instead,  a  collision-resistant,  one-way  hash  function  is  first  applied  to  the 
message  to  produce  a  fixed-length  digest  or  fingerprint  which  is  then  signed  using  the  signature  algorithm. 
The  overall  security  therefore  depends  on  both  the  traditional  digital  signature  algorithm  and  the  hash 
function.  Signature  servers  typically  have  significantly  more  computational  resources  available  to  them  than 
do  ordinary  users.  Hence  they  can  choose  a  higher  grade  security  (e.g.  much  longer  signature  keys)  from  a 
given  digital  signature  algorithm.  Thus,  S3  gives  ordinary  users  the  ability  to  produce  stronger  signatures 
than  they  could  have  been  able  to  by  using  traditional  signatures  by  themselves  in  the  standard  way. 

8  Related  Work 

Although  non-repudiation  of  origin  and  receipt  are  among  the  most  important  security  services,  only  a  few 
basic  protocols  exist.  See  [2]  for  a  summary  of  the  standard  constructions.  We  are  not  aware  of  any  previous 
work  that  aims  to  minimize  the  computational  costs  (at  the  protocol  level)  for  ordinary  users  while  providing 
the  same  security  as  standard  non-repudiation  techniques  based  on  asymmetric  cryptography. 

The  efficiency  problem  as  addressed  by  specific  designs  of  signature  schemes  was  mainly  motivated  by  the 
limited  computing  power  of  smart  cards  and  smart  tokens.  [12]  lists  most  known  proposals.  Typically  they 
are  based  on  pre-processing  or  on  some  asymmetry  in  the  complexity  of  signature  generation  and  verification 
(i.e. ,  either  sender  or  recipient  must  be  able  to  perform  complex  operations,  but  not  both).  Note  that 
although  server-supported  signatures  use  a  signature  scheme  that  is  asymmetric  with  respect  to  signature 
generation  and  verification,  ordinary  users  are  never  required  to  generate  signatures;  thus,  both  sender  and 
recipient  are  assumed  to  be  computationally  weak. 

In  his  well-known  paper  [6] ,  Lamport  proposed  using  hash  chains  for  password  authentication  over  inse¬ 
cure  networks.  There  had  been  other,  earlier  proposals  to  use  one-way  hash  functions  to  construct  signatures. 
Merkle  has  presented  an  overview  of  these  efforts  [7] .  The  original  proposals  in  this  category  were  impractical: 
a  proposal  by  Lamport  and  Diffie  requires  a  “public  key”  (i.e.  an  object  that  must  be  bound  to  the  signer 
beforehand)  and  two  hash  operations  to  sign  every  bit.  Using  an  improvement  attributed  to  Winternitz 
involving  a  single  public  key  (which  is  the  nth  hash  image  of  the  private  key)  and  n  hash  operations,  one 
can  sign  a  single  message  of  size  log2n  bits.  Merkle  introduced  the  notion  of  a  tree  structure  [7];  in  one 
version  of  his  proposals,  with  just  a  single  public  key,  it  is  possible  to  sign  an  arbitrary  number  of  messages. 
Nevertheless,  it  took  either  a  large  number  of  hash  operations  or  a  large  amount  of  storage  in  order  to  sign 
more  than  a  handful  of  messages  corresponding  to  the  same  public  key. 

Motivated  by  completely  different  factors,  Pfitzmann  et  al.  [10] [11,  Section  6.3.3]  proposed  a  fail-stop 
signature  protocol  which  uses  the  same  ideas  as  S3.  There,  the  signature  server  is  also  the  recipient  of 
the  signature  (which  is  a  sub-case  in  the  scope  of  S3),  and  the  goal  is  to  achieve  unconditional  security  for 
the  signer  against  the  server  (in  the  sense  of  fail-stop  signatures).  The  protocol  has  a  similar  structure  as 
the  one  in  Section  l.4  Because  of  the  specific  security  requirements,  all  parties  have  to  perform  complex 
cryptographic  operations,  and  signatures  are  not  easily  transferable. 

4  It  uses  a  so-called  bundling  function  h( )  instead  of  the  conceptionally  simpler  hash  function  used  in  S3 .  A  value  h(  a;)  is  used 
as  O’s  current  public  key.  To  give  a  NRO  token  for  message  m  to  S ,  the  signer  O  sends  m  to  S ,  which  answers  by  (m,  h(x))SK  5. 
Finally  O  sends  x  to  S ,  which  terminates  the  protocol.  The  NRO  token  for  S  is  (m,  h(x))SKs,  x-  The  consumed  public  key 
h{x)  can  be  renewed  by  including  a  new  public  key  h{x ;)  in  m. 
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Abstract 

One-time  signature  (OTS)  offer  a  viable  alternative  to  public  key-based  digital  signatures.  OTS  security  is  typically 
based  only  on  the  strength  of  the  underlying  one-way  function  and  does  not  depend  on  the  conjectured  difficulty  of 
some  mathematical  problem.  Although  many  OTS  methods  have  been  proposed  in  the  past,  no  solid  foundation  exists 
for  judging  their  efficiency  or  optimality.  This  paper  develops  a  methodology  for  evaluating  OTS  methods  and  presents 
optimal  OTS  techniques  for  a  single  OTS  or  a  tree  with  many  OTS’s.  These  techniques  can  be  used  in  a  seesaw  mode  to 
obtain  the  desired  tradeoff  between  various  parameters  such  as  the  cost  of  signature  generation  and  its  subsequent 
verification. 

©  2003  Elsevier  B.V.  All  rights  reserved. 
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1.  Introduction 

Modern  networks  and  Internetworks  are  more 
open  than  ever  before,  in  an  attempt  to  make  in¬ 
formation  available  on  a  ubiquitous  basis.  Net¬ 
works  are  also  faster  than  before,  with  available 
bandwidths  measured  in  Gb/s.  However,  instead 
of  alleviating  congestion  on  the  information 
highway,  this  has  only  encouraged  the  transmis¬ 
sion  of  greater  numbers  of  large  data  objects,  es¬ 
pecially  with  the  recent  popularity  of  multimedia 


presentations,  voice-  and  video-conferencing,  and 
large-scale  scientific  computing.  The  composition 
of  network  traffic  has  changed  from  yesterday’s 
text  files  to  today’s  enormous  datasets  produced  by 
sophisticated  remote  visualization  and  rendering 
tools. 

These  developments  make  it  important  to 
maintain  data  integrity  and  privacy  in  a  manner 
that  is  both  highly  secure  and  efficient.  Traditional 
digital  signature  methods  based  on  public  key 
cryptography  are  simply  untenable  from  a  per¬ 
formance  perspective.  Furthermore,  the  security  of 
public  key  cryptosystems  (e.g.,  RSA  or  DSS  [1,2]) 
is  based  on  complex  mathematical  problems,  such 
as  factoring  or  discrete  logarithms.  The  mathe¬ 
matical  basis  is  both  a  blessing  and  a  curse:  the 
former  because  it  lends  itself  to  simple  and  elegant 
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design,  and  the  latter  because  there  is  no  assurance 
that  there  are  no  efficient  algorithms  for  solving 
the  underlying  mathematical  problems. 

One-time  signature  (OTS)  provide  an  attractive 
alternative  to  public  key-based  signatures.  Unlike 
signatures  based  on  public  key  cryptography,  OTS 
is  based  on  nothing  more  than  a  one-way  func¬ 
tions  (OWFs).  1  Consequently,  OTSs  are  claimed 
to  be  more  efficient  since  no  complex  arithmetic  is 
typically  involved  in  either  OTS  generation  or 
verification.  In  practice,  security  of  traditional 
public  key-based  digital  signatures  is  based  on  two 
factors:  conjectured-hard  mathematical  problems 
and  the  message  digest  function  used  to  produce  a 
fixed-size  digest  from  arbitrarily  long  input  data. 
(A  secure  message  digest  function  suitable  for  this 
purpose  must  be  both  one-way  and  collision- 
resistant.)  Using  OTSs  essentially  allows  us  to 
eliminate  the  first  factor  altogether. 

The  OTS  concept  has  been  known  for  over  two 
decades.  It  was  initially  developed  by  Lamport  [6] 
and  subsequently  enhanced  by  Merkle  [7]  and 
Winternitz  [8].  Bleichenbacher  et  al.  [9-11]  for¬ 
malized  the  concept  of  OTS  using  directed  acyclic 
graphs  (DAGs). 

In  the  simplest  case,  a  message  signer  prepares 
an  OTS  by  first  generating  a  random  number  r 
which  serves  as  a  one-time  private  key.  The  signer 
then  securely  distributes  a  one-time  public  key 
h(r),  where  h(-)  is  a  suitable  collision-resistant 
OWF.  This  public  key,  sometimes  also  referred  to 
as  an  anchor  value,  is  later  used  by  the  signature 
verifier(s)  to  verify  the  signature. 

A  signature  is  constructed  by  revealing  the  one¬ 
time  private  key  r.  A  receiver  (verifier)  that  obtains 
r'  (which  may  or  may  not  be  the  same  as  r)  checks 
that  it  could  only  be  have  been  generated  by  the 
claimed  signer  by  computing  h(/).  If  this  value 
matches  the  one-time  public  key  h(r),  the  OTS  is 
considered  valid.  This,  in  effect,  allows  the  signing 
of  a  predictable  1-bit  value  and  provides  one-time 
origin  authentication.  In  order  to  sign  any  1-bit 
value,  two  random  numbers  {r0,  r, }  are  needed. 


1  Examples  of  conjectured  OWFs  include  DES  [3],  MD5  [4], 
and  SE1A  [5],  There  is  strong  (albeit,  folkloric)  evidence  as  to 
the  existence  of  true  OWFs. 


This  way,  both  h{rQ)  and  h(r\)  are  pre-distributed 
but  at  most  one  of  {r0,ri}  is  revealed  as  part  of  a 
signature.  The  pair  (r0,  h(r0))  represents  an  OTS  of 
message  “0”,  whereas  (r, ,  h(r\))  is  an  OTS  of  “1”. 

Merkle  extended  this  method  to  allow  the 
signing  of  an  arbitrary  message.  It  begins  by  re¬ 
ducing  the  message  to  a  fixed-length  quantity  using 
a  collision-resistant  message  digest  function,  as  is 
customary  with  traditional  public  key  signatures. 
However,  instead  of  transforming  this  quantity 
with  a  private  key,  each  bit  has  an  associated  OTS 
and  the  signature  for  the  entire  message  is  repre¬ 
sented  as  the  concatenation  of  the  OTS  for  each 
“1”  bit  in  the  message  digest,  along  with  some 
extra  values  to  ensure  that  this  per-bit  signature 
is  not  itself  modified. 

As  stated,  this  algorithm  requires  the  one-time 
public  keys  for  the  OTSs  to  be  distributed  in  a 
secure  fashion.  Since  this  is  typically  done  using 
public  key  methods,  the  benefit  of  using  efficient 
OTSs  is  apparently  lost.  However  in  [7],  Merkle 
also  introduced  a  scheme  where  these  signatures 
are  embedded  in  a  tree  structure,  allowing  the  cost 
of  a  single  public  key  signature  (to  sign  the  initial 
anchor  values)  to  be  amortized  over  many  OTSs. 
In  this  formulation,  signatures  are  longer,  by  at 
most  an  order  of  magnitude.  However,  the  extra 
length  (which  was  a  concern  two  decades  ago)  is 
negligible  today  owing  to  the  high  speed  of  mod¬ 
ern  networks. 

Despite  their  performance  advantage  and  in¬ 
creased  security,  OTSs  have  remained  on  the  pe¬ 
riphery  of  security  research  since  their  inception. 
In  particular,  no  practical  evaluation  of  OTS  ca¬ 
pabilities  has  been  done.  This  open  issue  is  pre¬ 
cisely  the  topic  of  the  present  paper.  In  order  to 
obtain  better  understanding  of  OTS  optimality,  we 
first  address  a  more  general  issue  of  how  to  max¬ 
imize  the  message  size  (of  a  message  to  be  signed) 
while  minimizing  the  number  of  random  quantities 
to  be  used  in  OTS  generation  (and,  hence,  the 
number  of  OWF  operations).  Our  result  leads  us 
towards  an  optimal  OTS  construction  where  effi¬ 
ciency  corresponds  to  the  smallest  number  of 
OWF  operations  used  in  both  generation  and 
verification  of  an  OTS.  We  then  amend  this  defi¬ 
nition  of  efficiency  to  take  into  account  situations 
where  multiple  verifications  are  necessary,  e.g., 
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with  multi-destination  e-mail  or,  more  generally, 
secure  multicast.  This  leads  us  to  consider  a 
slightly  different  notion  of  optimality. 

The  outline  of  the  paper  is  as  follows.  After 
introducing  Merkle's  signature  algorithm  in  Sec¬ 
tion  2,  we  generalize  the  OTS  constructions  and 
present  our  optimal  technique  in  Section  3.  We 
evaluate  the  performance  of  our  OTS  construction 
in  directed  acyclic  computation  graph  notation  in 
Section  4.  Section  5  is  for  describing  how  to  en¬ 
code  a  message  for  the  signature  using  our  tech¬ 
nique.  We  make  the  cost  analysis  of  a  single  OTS 
or  a  tree  with  many  OTSs  in  Sections  6  and  7, 
respectively.  In  Section  8,  we  present  a  method  to 
construct  the  optimal  tree,  more  precisely  we  show 
how  to  choose  the  optimal  depth  of  this  tree. 
Section  9  discusses  practical  implementation  as¬ 
pects  and  possibilities  for  future  work  and  Section 
10  concludes  this  paper. 

2.  Merkles  one-time  signature  construction 

One  notable  and  efficient  OTS  construction 
is  due  to  Merkle  [12].  (Others  can  be  found  in 
[13,14].)  Assuming  input  messages  of  size  b ,  let 
s  =  ( [log  b\  +  1)  and  let  n  =  b  +  s.  The  signer 
generates  a  secret  key  vector  of  size  (b  +  2s)  of 
random  numbers: 

R  =  {R\,  ■  ■  ■  ,RbiL i,o, Ti  i,  ■  ■  ■  ,4s,o,Ts,i}. 

The  signer  then  applies  the  OWF  to  each  element 
of  the  secret  key  vector  and  distributes  the  result¬ 
ing  public  key  vector  to  the  intended  verifier(s): 

H{R)  =  (H(Rl),...,H{Rb),H(Lifi), 

Subsequently,  to  sign  a  b-bit  message  m,  the  signer 
counts  the  number  of  “1”  bits  in  m,  encodes  the 
count  as  an  .s-bit  string  and  appends  it  to  m.  The 
result  is  an  /7-bit  message  in'.  The  actual  signature 
SIG(tm)  is  constructed  as  follows: 

for  i  =  1  to  b  do  begin 

if  (m[i\  ==  1)  then  /*  /th  bit  of  m'  is  “1”  */ 
release  H{R,) 

end  /*  for  */ 

for  i  =  (b  +  1)  to  n  do  begin 


if  (/77  [/']  ==  1) 

release  H{Ll\) 
else 

release  H(LU 0) 

end  /*  for  */ 

For  example,  if  b  =  4  (thus,  n  =  7)  and 
777  =  0101,  then  m'  =  0101010  and  SIGH  = 
{7?2, Ra, Li,o,L2,i, £3,0}-  The  verifier  checks  the  sig¬ 
nature  by  applying  H  to  each  element  of  SIG(/m) 
and  checking  it  against  the  public  key  vector  H  (R). 

To  summarize  the  cost  of  Merkle’s  OTS  con¬ 
struction,  the  signer  generates  (. b  +  2s)  random 
numbers  and  performs  as  many  OWF  computa¬ 
tions.  Each  verifier  performs,  on  the  average, 
(b/2  +  5)  OWF  computations.  For  example,  for  a 
160-bit  message  (e.g.,  an  SHA1  digest),  176  and  88 
OWF  operations  are  needed  to  sign  and  verify, 
respectively. 

Despite  its  relatively  low  cost  and  simplicity,  the 
above  is  basically  an  ad  hoc  construction.  No  ar¬ 
gument  for  its  optimality  has  been  provided  in 
Merkle’s  work.  Moreover,  it  remains  unclear  what 
optimality  means  in  the  context  of  an  OTS  system. 

3.  One-time  signature  generalization 

More  generally,  a  message  sender  prepares  a 
signature  by  generating  an  //-element  random 
number  vector  R  =  (n,r2, . . .  ,r„).  He  then  com¬ 
putes  H(R)  =  (H(ri),H(r2), . . .  ,H(r„ ))  where  H(-) 
is  a  suitable  OWF.  The  sender  then  securely  dis¬ 
tributes  the  one-time  public  key  vector  H(R)  to 
all  intended  verifiers. 

Signature  generation  is  the  process  of  mapping 
the  input  message  into  a  subset  S  C  R.  S  is  then 
attached  to  the  message  as  its  signature.  To  verify 
S,  each  receiver  computes  a  similar  mapping  from 
the  input  message  into  a  subset  T  of  H(R).  The 
signature  is  considered  valid  only  if  T  =  H(S). 

The  mapping  function  must  satisfy  a  condition 
which  we  refer  to  as  incomparability:  for  any 
message  D\,  an  attacker  must  be  unable  to  find 
another  message  D2  such  that  F(D2)cF(D\) 
where  F(Dt)  corresponds  to  signature  subset  S,  for 
the  message  D,.  Otherwise,  if  the  legitimate  signer 
distributes  (DuF(Di)),  the  attacker  could  replace 
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D\  with  D2,  reduce  the  set  F{D\)  to  F{D2),  and 
obtain  a  valid  message-signature  pair  ( D2lF(D2 )). 

This  leads  us  to  ask  the  question:  When  R  con¬ 
tains  n  random  numbers,  how  many  distinct  mes¬ 
sages  can  be  signed  or  in  other  words  what  would  be 
the  maximum  size  of  the  message  space? 

For  n  =  1,  the  answer  is  one,  and  the  signature 
is  one  random  number.  For  n  =  2,  the  answer  is 
two:  the  signature  can  be  either  r\  or  r2.  If  we  were 
to  map  a  message  onto  the  signature  subset 
{r, ,  r2},  that  choice  would  eliminate  any  other 
subset,  allowing  a  single  distinct  message. 

In  general,  we  observe  that,  for  any  n,  we  can 
obtain  a  valid  message  mapping  by  drawing  from 
all  subsets  containing  p  <  n  random  numbers. 
Clearly,  no  one  such  subset  can  be  the  subset 
of  another,  allowing  us  C(n,p)  =n\/p\ (n  —  p)\ 
distinct  messages. 

In  [15],  it  is  shown  that  for  any  n,  the  domain  of 
mapping  M  is  greatest  when  p  =  [n/2J.  This  al¬ 
lows  us  to  sign  any  one  of 

S"=(L«/2j)  (1) 

distinct  messages,  i.e.,  we  are  able  to  sign  an 
arbitrary  (logfi„)-bit  message.  For  example,  if  R 
contains  four  elements  1,  2,  3,  and  4,  then  the 
largest  valid  message  set  of  R  is 

F  =  {{1,2},  {1,3},  {1,4},  {2,3},  {2,4},  {3,4}} 

which  contains  B\  =  6  elements. 

By  inverting  this  formula,  and  using  Stirling’s 
approximation,  we  can  see  that  to  represent  2* 
distinct  values,  n  must  satisfy 

Bn  >  2\ 

V2fm{n/e)"  >  jb 
[y/n Ti(n/2e)n,1f 

2nyj2/nn  >  2h 

or,  after  taking  base  2  logarithm  of  both  sides, 

n  -  lg  \J nn/2  >  b.  (2) 

For  b  =  128  (e.g.,  MD5),  n  must  be  at  least  132, 
and  each  subset  can  be  as  small  as  size  64,  since 
C(132, 64)  >  2128.  For  b  =  160  (e.g.,  SHA1),  n 


Fig.  1 .  Signature  generation/verification  hash  profile. 


must  be  at  least  165  (n  =  164  is  just  barely  insuf¬ 
ficient),  with  subsets  of  size  75. 

Note  that  we  can  freely  increase  n  and  decrease 
p,  or  similarly,  decrease  n  and  increase  p,  provided 
C(n,p )  >  2b  and  the  signer  and  verifier(s)  decide 
beforehand  on  the  values  of  n  and  p.  At  one  ex¬ 
treme,  as  we  have  shown,  there  is  the  lowest  n  such 
that  there  exists  a  p  so  that  C(n,p)  >  2b.  At  the 
other  extreme,  one  could  choose  n  =  2h,  and  allow 
p  =  1 ;  this  would  correspond  to  the  case  where 
there  is  a  random  number  associated  with  each 
possible  message,  and  the  sender  simply  picks  the 
appropriate  one  for  each  message  to  be  signed! 
(This  is  clearly  an  intractable  storage  problem.) 

In  Fig.  1,  we  show  the  number  of  random 
numbers  n  versus  the  number  of  hashes  required 
for  verification  p ,  for  two  popular  message  (digest) 
sizes. 

We  also  observe  that,  for  a  valid  (n,p)  pair 
satisfying  C(n,p)  >  2'\  if  the  anchor  values  II (R) 
are  encrypted,  the  release  of  a  subset  in  V  con¬ 
taining  p  numbers  can  be  used  to  exchange  b  bits 
of  confidential  information,  since  no  one  observing 
the  p  numbers  can  distinguish  them  from  any 
others,  or  verify  them,  without  being  able  to  de¬ 
crypt  H(R) . 

4.  Efficiency  assessment  using  directed  acyclic 
graphs 

Bleichenbacher  et  al.  [9-11]  formalized  the 
concept  of  OTS  using  DAGs.  They  observed  that 
the  structure  of  the  OTS  computation  leading 
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from  the  secret  key  components  to  the  public  key 
can  be  represented  as  a  DAG  G=(V,E)  with 
vertex  set  V  and  and  edge  set  E,  where  the  vertices 
correspond  to  the  secret  key,  the  intermediate  re¬ 
sults,  and  the  public  key,  and  where  a  directed 
edge  (vj,  Vj )  in  E  indicates  that  a,-  is  an  input  to  the 
OWF  and  computation  resulting  in  Vj. 

In  order  to  design  a  OTS  based  on  a  DAG, 
there  are  two  important  requirements.  First,  every 
OTS  must  be  verifiable,  i.e.,  the  public  key  must  be 
computable  from  it.  Second,  in  order  to  prevent 
forgery,  the  set  of  signatures  must  satisfy  the  im- 
comparability  condition  defined  in  previous  sec¬ 
tion. 

If  we  assume  that  all  the  public-key  components 
are  hashed  in  a  binary  tree  to  result  in  a  single 
public-key  component,  then  an  efficient  OTS  al¬ 
gorithm  can  be  formally  defined  as  one  in  which 
the  size  of  the  message  space  is  maximized  while 
the  size  of  the  DAG  is  minimized.  More  precisely, 
if  lg(F)  is  the  number  of  message  bits  that  can  be 
signed,  the  efficiency  of  a  one-time  digital  signature 
scheme  F  for  a  DAG  G  with  z  =  \  V\  vertices  is 
given  by 


'7(0 


lg(0 

z+  1  ' 


In  [10],  the  authors  also  presented  their  best  graph 
construction,  for  which  the  efficiency  is  approxi¬ 
mately  equal  to  0.473.  We  will  now  prove  that  our 
methodology  provides  a  better  construction  in 
terms  of  their  notion  of  efficiency. 

In  the  previous  section,  we  showed  that  the 
number  of  bits  that  can  be  signed  using  n  random 
numbers  is  upper  bounded  by  n  —  lg  yjmi/l.  In 
Fig.  2,  we  demonstrate  that  when  we  assemble  the 
DAG  of  our  construction  with  n  random  numbers, 
the  number  of  vertices  is  equal  to  2 n  +  1 .  Then  the 
efficiency  is  upper  bounded  by  0.5  as  seen  from  Eq. 
(3). 


lim  a-l8yW2  =  o.5.  (3) 

n-> oo  Zfl  Z 

For  b  =  128  (e.g.,  MD5),  this  value  is  0.4812  and 
for  b  =  160  (e.g.,  SHA1),  it  is  0.4819.  We  observe 
that  both  of  them  is  better  than  the  best  con¬ 
struction  in  [10]. 


Fig.  2.  The  DAG  representation  of  our  construction  for  n  =  4 
(z  =  2n  +  1  =  9)  where  the  public-key  components  are  hashed  in 
a  binary  tree  to  result  in  a  single  public-key  component.  To 
make  the  OTS  verifiable,  the  signature  contains  the  random 
numbers  released  as  well  as  the  hashes  of  unreleased  random 
numbers. 

Other  than  the  efficiency  concerns,  we  claim 
that  our  methodology  is  better  than  Bleichen- 
bacher  et.  al.’s  approach  in  two  aspects: 

•  In  practice,  their  proposed  DAG  construction  is 
very  complex  and  hard  to  implement  whereas 
our  combinatorial  results  are  elementary  and 
easy  to  grasp. 

•  In  [10],  the  authors  did  not  discuss  how  to  en¬ 
code  a  specific  message  for  the  DAG  they  used. 
In  contrast,  we  provide  an  efficient  method  for 
encoding  a  message  for  signature  in  the  next 
section. 

5.  Encoding  a  message  for  signature 

Given  a  vector  R  of  n  random  numbers,  and  a 
valid  message  set  V  of  subsets  each  containing  p  of 
those  numbers,  we  have  shown  that  we  can  sign 
any  one  of  C(n,p)  distinct  messages.  In  this  sec¬ 
tion,  we  describe  the  mapping  M  between  messages 
and  the  elements  of  V,  and  demonstrate  how  to 
compute  them  efficiently. 

Assume  that  the  domain  of  M  is  composed  of  2h 
messages,  and  we  have  a  way  of  representing  each 
of  the  messages  as  a  b-bit  integer  m.  Let  any  subset 
S  in  V  be  expressed  as  {Rai ,  Ra2, . . . ,  RUp}.  Arrange 
the  subsets  in  V  in  lexically  ascending  order.  For 
example,  for  n  =  4,  p  =  2,  the  subsets  are  ordered 

{R\,R2},  {Ri,R}},  {Ri,R4},  {R2,R2}, 

{^2,^4},  {R2,R4}. 
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Then  the  mapping  m  =  M(S,  V)  of  each  subset  S  is 
defined  as  the  integer  position  of  S  in  this  list 
representation  of  V.  For  example,  in  the  above 
case,  V)  =2  and  M{{R^R4\,  V )  =  6. 

In  general,  for  any  n  and  p,  the  mapping  of  any 
subset  S  =  {Rai,Rai, . . .  ,Rap},  where  a0  =  0  and 
czi  <  a2  <  •  •  •  <  ap  is  given  by 


p  n—cii-\  —  1 

M(S,F)  =  l  +  £  £ 

1=1  j—n—di+l 


(4) 


Note  that  in  order  to  compute  the  mapping  for 
any  subset,  for  a  given  n  and  p,  we  need  only 
compute  the  binomial  coefficients  C(j,p  -  i)  for  i 
from  1  to  p,  j  from  p  +  1  —  i  to  n  —  i.  Thus,  each 
mapping  requires  n  —  p  —  (n  —  ap )  =  ap—  p  addi¬ 
tions. 

Similarly,  the  mapping  S  =  M~{(m1V)  of  a 
message  represented  by  the  integer  m  can  be 
computed  by  subtracting  binomial  coefficients 
until  zero  is  reached.  This  requires  ap  -  p  additions 
and  comparisons.  Pseudocode  to  do  this  conver¬ 
sion  is  as  follows: 


mq  =  m  /*  copy  message  to  temporary  value  *1 

q  =  1 

for  i  =  1  to  p  do  begin 

while  m0  >  C(n  —  q.p  —  i )  do  begin 
;«o  :=  mo  —  C{n  —  q,p  —  i) 
q  :=  q  +  1 
end  /*  while  */ 
a,  :=  q 
q  :=  q  +  1 
end  /*  for  */ 

To  put  things  in  perspective,  consider  that  a 
single  MD5  hash  computation  requires  approxi¬ 
mately  500  arithmetic  operations.  Thus,  our 
mapping  (in  both  directions)  costs  less  than  one 
MD5  hash. 


6.  Cost  analysis  of  a  single  one-time  signature 

6.1.  All  on-line  case 

In  the  preceding  sections,  we  showed  how  to 
sign  an  arbitrary  h-bit  message  using  p  of  n  ran¬ 


dom  numbers.  In  this  section,  we  will  describe  how 
to  choose  n  and  p  to  minimize  the  total  cost  of  a 
OTS.  Our  initial  assumption  is  that  all  of  the 
signing  process  is  performed  on-line,  once  the 
message  is  presented. 

The  principal  cost  of  generating  a  OTS  (aside 
from  the  cost  of  securely  distributing  the  anchor 
values  H(R))  is  the  cost  of  computing  H(R);  this 
costs  n  hashes.  The  principal  cost  of  verifying  a 
OTS  (aside  from  the  cost  of  verifying  the  anchor 
values)  is  the  cost  of  computing  H(S);  this  costs  p 
hashes.  However,  only  a  single  sender  generates  a 
OTS,  while  potentially  many  receivers  verify  it. 
Thus,  each  hash  involved  in  signature  verification 
incurs  a  greater  cost  than  one  involved  in  signature 
generation. 

In  general,  let  each  verification  hash  cost  a 
times  as  much  as  a  generation  hash.  The  total  cost 
of  a  single  signature  is  then  proportional  to  n  +  ap\ 
this  is  the  quantity  that  we  shall  try  to  minimize, 
subject  to  the  condition  that  C(n,p)  >  2h. 

We  want  to  find  n  and  p  such  that 
C(n,p)=C(n  +  a,p  —  1).  As  a  first  approximation, 
we  have,  from  the  definition  of  the  binomial  co¬ 
efficient 


/  n  \a.n—p 
\n-p)  p 

If  we  let  a  =  p/n ,  we  have 


(5) 

(6) 


«  =  r+1-  (7) 

To  find  the  optimal  n  and  p,  we  find  the  p  such  that 
C([apJ,p)  >  2h. 


6.2.  On-line/ off-line  case 


In  [14],  the  authors  introduce  the  new  concept 
of  on-line/off-line  digital  signature  schemes.  In 
these  schemes  the  signing  of  a  message  is  broken 
into  two  phases.  The  first  phase  is  off-line.  Though 
it  requires  a  moderate  amount  of  computation,  it 
presents  the  advantage  that  it  can  be  performed  at 
leisure,  before  the  message  to  be  signed  is  even 
known.  The  second  phase  is  on-line  and  it  starts 
after  the  message  becomes  known.  Since  it  utilizes 
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the  precomputation  of  the  first  phase,  it  is  much 
faster. 

We  observe  that  the  signer  can  generate  the 
vector^  =  {/?i, . . .  ,R„},  and  by  applying  the  OWF 
to  each  random  number,  he  can  generate  the  ha¬ 
shes  off-line.  The  on-line  phase  is  just  a  mapping 
and  at  the  end  of  Section  5  we  showed  that  it  costs 
less  than  one  MD5  hash  operation.  So,  in  this  case 
we  try  to  minimize  the  verification  time.  This  is 
also  due  to  the  fact  that  many  times  only  a  single 
sender  generates  an  OTS,  but  potentially  many 
receivers  verify  it. 

It  is  improper  to  take  the  verification  time  as 
only  the  time  needed  to  make  the  mapping  and 
generate  the  hashes  of  the  random  numbers.  One 
of  the  disadvantages  of  OTS  is  its  length;  especially 
if  we  have  a  low  bandwidth  channel,  the  time 
needed  to  transmit  the  signature  dominates  the 
time  for  verification  and  cannot  be  neglected.  Also, 
available  bandwidth  and  computation  power  both 
vary  over  a  wide  range.  We  may  therefore  optimize 
n  and  p  with  respect  to  bandwidth  and  computa¬ 
tion  power. 

Here,  we  will  describe  how  to  choose  n  and  p  to 
minimize  the  total  time  T  needed  to  verify  one 
OTS.  Let’s  take  the  hash  length  as  b  and  random 
number  length  as  a.  Assume  a  bandwidth  of  K 
bits/s  and  L  seconds  as  the  time  required  to  per¬ 
form  one  hash  operation.  Then 

T=m±^+{p+l)L+m.  (8) 

In  the  above  formula,  we  ignore  other  delays  such 
as  queuing  delays.  The  extra  L  is  for  generating  the 
hash  of  the  message,  and  m  is  the  time  to  compute 
the  mapping.  The  total  time  needed  to  verify  one 
OTS  is  then  proportional  to  n  +  op  where 


This  optimization  therefore  reduces  to  the  one 
analyzed  in  the  previous  section. 

7.  Amortized  cost  of  many  signatures 

Using  the  OTS  only  once  is  inefficient,  since  the 
sender  needs  to  sign  the  original  hash  image  H(R) 


Fig.  3.  Tree  scheme  for  maintaining  signature  vectors. 


using  a  conventional  digital  signature  (e.g.,  DSS). 
Using  Merkle’s  tree  scheme  [12]  as  illustrated  in 
Fig.  3,  we  can  sign  an  arbitrarily  large  number  of 
messages  with  only  one  conventional  signature. 
However,  the  incremental  cost  of  generating  and 
verifying  an  additional  signature  increases  loga¬ 
rithmically  with  the  number  of  signatures. 

In  the  tree  scheme,  one  constructs  a  tree  of 
signature  nodes.  Each  signature  node  has  a  vector 
for  signing  each  of  its  children  as  well  as  a  single 
message.  The  root  node  is  signed  by  conventional 
means — i.e.,  using  a  digital  signature  key. 

One  of  the  built-in  features  of  Merkle’s  OTS 
tree  construct  is  the  ability  to  unambiguously  or¬ 
der  signatures.  This  is  a  very  useful  service  in  many 
application  domains.  For  example,  it  is  imperative 
in  a  military  environment  to  establish  strict  cau¬ 
sality  of  commands  (and  signed  orders  in  general). 
Failure  to  do  so  can  have  disastrous  consequences 
since  re-ordered  messages  can  lead  to  devastating 
mistakes  on  the  battlefield.  In  the  civilian  realm, 
signature  ordering  is  very  important  in  electronic 
commerce,  among  other  fields. 

Consider  a  binary  tree  such  that  each  node  has 
three  vectors  and  suppose  that  we  choose  n  and  p 
such  that  C(n,p)  >  2b.  We  would  like  to  compute 
the  cost,  in  hashes,  of  generating  and  verifying  a 
signature  at  any  given  depth  d. 

To  generate  the  signature,  one  needs  to  do  a 
OTS  of  the  message  (requiring  n  hashes).  Assum¬ 
ing  the  signer  can  cache  the  tree,  no  further  com¬ 
putation  is  required. 
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Verification  requires  one  to  perforin  p  hashes  to 
verify  the  current  node’s  signature  of  the  message, 
and  an  additional  p  hashes  to  verify  the  parent 
node’s  signature  of  the  current  node.  If  the  receiver 
has  cached  the  tree,  no  further  computation  is  re¬ 
quired;  otherwise,  an  additional  (d  —  l)p  hashes 
are  required. 

In  contrast  to  the  single  signature  case,  then, 
each  of  a  sequence  of  signatures  costs  n  +  2 p 
hashes  if  receivers  cache  the  signature  tree,  or 
n  +  {cl  +  \  )p  hashes  if  they  do  not.  How  reason¬ 
able  is  it  to  cache  a  signature  tree?  If  we  choose 
SHA  as  our  message  digest,  we  need  to  sign  160 
bits  of  message,  for  which  we  could  choose 
n  =  165  and  p=  82.  Both  signer  and  verifier 
must  cache,  for  each  node,  3 n  160-bit  numbers 
(the  signer  caches  the  random  numbers  R ,  the 
verifier  caches  the  anchor  values  //  (/?));  this 
works  out  to  4950  bytes  per  node.  This  is  easily 
supported. 

In  fact,  receivers  who  cache  the  tree  need  only 
maintain  the  lowest  layer  of  nodes,  so  that  only 
about  half  the  nodes  already  traversed  need  be 
kept  at  any  time.  They  can  prune  additional  in¬ 
formation  off  the  tree  by  removing  the  message 
signature  vectors  after  they  are  exhausted. 


8.  Constructing  the  optimal  tree 

In  Section  4,  we  showed  how  to  choose  n  and  p 
to  minimize  the  total  cost  of  an  OTS.  In  this  sec¬ 
tion,  we  will  describe  how  to  choose  the  parame¬ 
ters  of  a  k- ary  tree  with  a  depth  of  d.  Note  in 
particular  that  the  tree  structure  does  not  need  to 
be  binary.  Also,  we  should  stop  somewhere  in  our 
tree;  at  some  point  the  cost  of  using  our  large  tree 
to  verify  an  OTS  is  more  than  that  of  starting  a 
new  tree  in  which  we  have  signed  the  root  node  by 
conventional  means.  In  other  words,  we  need  to 
optimize  the  value  of  d. 

We  will  try  to  minimize  the  average  verification 
cost  of  one  OTS.  Suppose  that  the  verifier  only 
caches  the  root  node  of  the  tree.  This  is  a  rea¬ 
sonable  assumption,  especially  when  the  signer 
uses  the  tree  to  sign  messages  for  different  receiv¬ 
ers.  Suppose  also  that  the  cost  of  verifying  a  tra¬ 


ditional  signature  is  C  times  more  than  verifying 
a  OTS.  In  a  k- ary  tree  with  a  depth  of  d,  the 
number  of  messages  that  can  be  signed  is 


kd  -  1 
k  —  1 


and  the  number  of  OTS  required 


dkk+l  ~{d+  l)A-rf  +  1 

(*-l)2 


In  a  single  tree,  the  cost  per  message  is 

c+w  _c  +  Y:Uyky-1 
N  EUk-v~l 


(10) 


We  try  to  find  the  smallest  d  such  that  the  average 
cost  per  message  is  smaller  than  it  is  for  d  +  1 . 

At  optimal  d. 


C  +  E^i1  yky-'  ^C  +  Eti yk*~l 
E dyt\k>-1  E.y=l  ^ 


which  is  approximately  equivalent  to 

C+(d+  \)kd  +  W=k(C+  W).  (11) 

If  we  put  W  into  its  place  and  make  necessary 
manipulations,  our  formula  becomes 


kd+l=(k  —  1)2C+  1. 


Then,  we  can  give  the  optimal  tree  depth  d  as 


log p-Hfc  +  2! 
logk 


(12) 


In  Fig.  4,  we  show  the  depth  of  a  binary  tree  versus 
average  normalized  verification  cost  per  message. 
One  should  choose  the  depth  d  where  the  average 
normalized  cost  per  message  is  minimal. 

Secondly,  we  would  like  to  introduce  a  way  to 
decide  on  the  value  of  k.  Suppose  the  signer 
caches  the  tree  and  S  be  the  storage  requirement 
for  one  random  vector  and  its  corresponding 
hash  values.  Then  the  storage  cost  per  message  is 
(k+  1  )S,  which  is  independent  of  d.  Suppose  also 
that  the  storage  cost  per  message  is  at  most  M. 
Then 


(13) 
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So  after  estimating  k  with  this  simple  formula,  we 
can  also  find  d  by  using  the  previous  formula 
above. 


9.  Implementation  and  future  work 

In  practical  implementations,  OTS  use  closely 
resembles  that  of  public  key  signatures.  For  in¬ 
stance,  in  OTS,  the  sender  distributes  a  certifi¬ 
cate,  which  contains  a  public  value,  signed  by  a 
certification  authority.  The  only  difference  is  that 
the  public  value  here  is  a  sequence  of  hash 
function  outputs  (or  a  single  output  if  these 
components  are  hashed  in  a  single  hash  value), 
rather  than  a  public  key.  Just  as  before,  this 
certificate  can  be  distributed  in  advance  of  the 
signed  message,  or  it  can  accompany  the  signed 
message.  Finally,  the  signature  represents  a 
transformation  of  a  message  digest  of  the  overall 
message;  the  only  differences  are  in  the  details  of 
that  transformation. 


There  is  a  clear  analogy  to  traditional  digital 
signature  algorithms,  which  is  summarized  by  the 
diagram  below: 

message  digest  <*=>■  message  digest 
encryption  with  private  key 
<^=>-  mapping  to  OTS  random  values 
verification  with  public  key 
<=>  verification  via  OTS  anchors 

Currently,  we  have  implemented  an  OTS  library 
which  utilizes  the  suggested  mapping  and  the  tree 
structure.  We  will  investigate  the  effect  of  changing 
the  parameters  to  make  it  more  efficient. 

Subsequently,  we  will  integrate  our  OTS  library 
into  specific  applications  that  require  fast  digital 
signatures.  One  of  the  anticipated  application  do¬ 
mains  is  as  an  integrity  mechanism  in  Active  Net¬ 
works.  One  of  the  basic  tenets  of  the  Active 
Networks  concept  is  the  use  of  so-called  “smart 
packets,”  packets  that  carry  the  means  for  their 
own  handling  in  routers  and  other  network  entities. 
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This  paradigm  immediately  raises  a  number  of  se¬ 
curity  issues,  data  integrity  and  origin  authentica¬ 
tion  being  chief  among  them.  For  this  reason,  we 
maintain  that  ultra-fast  digital  signatures  are  an 
absolute  must  for  Active  Networks  to  be  practical. 

The  results  of  our  research  will  also  be  of 
interest  to  an  intrusion  detection  system.  Authen¬ 
ticating  the  source  and  contents  of  a  response 
request  is  fundamental  to  the  survivability  of 
the  systems  at  hand.  At  the  same  time,  responses 
must  also  be  executed  in  a  timely  fashion  and  not 
be  allowed  to  queue  indefinitely.  We  expect  that 
OTS  will  provide  a  way  for  components  of  intru¬ 
sion  detection  systems  to  quickly  and  efficiently 
establish  the  integrity  of  the  messages  they  ex¬ 
change. 


10.  Conclusion 

We  have  provided  a  theoretical  foundation  for 
evaluating  the  efficiency  and  compactness  of  one¬ 
time  digital  signatures.  This  work  reveals  the  ab¬ 
solute  minimum  complexity  of  computing  a  digital 
signature  over  a  space  of  6-bit  messages,  based  on 
the  weighted  costs  of  signature  generation  and 
verification.  We  have  shown  how  this  theoretical 
minimum  can  be  achieved  by  using  a  simple  and 
efficient  mapping  between  messages  and  subsets  of 
random  numbers.  We  have  demonstrated  how  this 
family  of  OTS  schemes  fits  into  an  elegant  proto¬ 
col  for  amortizing  the  cost  of  OTSs  over  many 
messages.  Finally,  we  have  provided  a  theoretical 
foundation  for  evaluating  the  efficiency  of  the  OTS 
tree  structure  based  on  the  weighted  costs  of  tra¬ 
ditional  and  OTSs. 
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Abstract.  One-time  signatures  (OTS)  offer  a  viable  alternative  to  public  key- 
based  digital  signatures.  OTS  security  is  based  only  on  the  strength  of  the 
underlying  one-way  function  and  does  not  depend  on  the  conjectured  difficulty 
of  a  mathematical  problem.  OTS  methods  have  been  proposed  in  the  past  but  no 
solid  foundation  exists  for  judging  their  efficiency  or  optimality.  This  paper 
develops  a  new  methodology  for  evaluating  OTS  methods  and  presents  optimal 
OTS  techniques  for  a  single  OTS  or  a  tree  with  many  OTSs.  These  techniques 
can  be  used  in  a  see-saw  mode  to  obtain  desired  tradeoff  between  various 
parameters  such  as  the  cost  of  signature  generation  and  its  subsequent 
verification  and  the  cost  of  traditional  signature  verification  and  OTS 
verification. 


1  Introduction 

Digital  signatures  are  rapidly  becoming  ubiquitous  in  many  spheres  of  computing. 
Most  current  techniques  for  generating  digital  signatures  are  based  on  public  key 
cryptography,  e.g.,  RSA  or  DSS  [12,  3],  These,  in  turn,  are  based  on  complex 
mathematical  problems  such  as  factoring  or  discrete  logarithms.  This  solid 
mathematical  basis  is  both  a  blessing  and  a  curse:  the  former  because  it  lends  itself  to 
simple  and  elegant  design  and  the  latter  because  there  is  no  assurance  that  efficient 
algorithms  do  not  exist  for  solving  the  underlying  mathematical  problems. 

One-time  signatures  (OTS)  provide  an  attractive  alternative  to  public  key-based 
signatures  since— unlike  signatures  based  on  public  key  cryptography— OTS  is  based 
on  nothing  more  than  a  one-way  function  (OWF).  Examples  of  conjectured  OWFs 
include  DES  [10],  MD5  [11],  and  SHA  [9].  There  is  strong  (albeit  folkloric)  evidence 
as  to  the  existence  of  true  OWFs.  Furthermore,  OTSs  are  claimed  to  be  more  efficient 
since  no  complex  arithmetic  is  typically  involved  in  either  OTS  generation  or 
verification. 
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The  OTS  concept  has  been  known  for  almost  two  decades.  It  was  initially  developed 
by  Lamport  [4]  and  enhanced  by  Merkle  [8]  and  Winternitz  [7].  For  the  sake  of 
brevity,  we  do  not  review  the  history  of  OTS  research  here;  we  defer  instead  to  [6,  5] 
for  a  comprehensive  treatment  of  the  subject. 

One  efficient  OTS  construction  is  due  to  Merkle  [6].  (Other  efficient  constructions 
can  be  found  in  [1]  [2].)  To  summarize  the  cost  of  Merkle’s  OTS  construction,  the 
signer  generates  n  =  (b+log  b)  random  numbers  and  performs  n  OWF  computations. 
Each  verifier  performs,  on  the  average,  n/2  OWF  computations  which  yields  the 
average  total  of  1.5  *  (b+log  b).  If  we  were  to  sign  a  128-bit  message  (e.g.,  an  MD5 
digest)  an  average  of  202  OWF  operations  would  be  necessary. 

Despite  its  relatively  low  cost  and  overall  elegance,  this  is  basically  an  ad  hoc 
construction.  No  argument  for  its  optimality  has  been  provided  in  Merkle’s  work. 
Moreover,  it  remains  unclear  what  optimality  means  in  the  context  of  an  OTS  system. 
This  open  issue  is  precisely  the  topic  of  this  paper.  In  order  to  obtain  better 
understanding  of  OTS  optimality,  we  first  address  a  more  general  issue  of  how  to 
maximize  the  message  size  (of  a  message  to  be  signed)  while  minimizing  the  number 
of  random  quantities  to  be  used  in  OTS  generation  (and,  hence,  the  number  of  OWF 
operations).  Our  result  leads  us  towards  an  optimal  OTS  construction  where 
efficiency  corresponds  to  the  smallest  number  of  OWF  operations  used  in  both 
generation  and  verification  of  an  OTS.  We  then  amend  this  definition  of  efficiency  to 
take  into  account  situations  where  multiple  verifications  are  necessary,  e.g.,  with 
multi-destination  e-mail  or,  more  generally,  secure  multicast.  This  causes  us  to 
consider  a  slightly  different  notion  of  optimality. 

2  One-Time  Signature  Generalization 


The  question  we  are  trying  to  find  an  answer  is  how  many  distinct  messages  can  be 
signed  when  R  contains  n  random  numbers?  For  n  =  1,  the  answer  is  one,  and  the 
signature  is  the  one  random  number.  For  n  =  2,  the  answer  is  two:  the  signature  can  be 
either  r  or  r2.  If  we  were  to  map  a  message  onto  the  signature  subset  { rh  r2},  that 
choice  would  eliminate  any  other  subset,  allowing  us  only  one  distinct  message.  In 
general,  we  observe  that,  for  any  n,  we  can  obtain  a  valid  message  mapping  by 
drawing  from  all  subsets  containing  p  <  n  random  numbers.  Clearly,  no  one  such 
subset  can  be  the  subset  of  another,  allowing  us  C(n,p)  =  n!/p!(n-p)!  distinct 
messages.  In  [13],  it  was  shown  that  for  any  n,  the  domain  of  mapping  M  is  greatest 
when  we  draw  from  all  subsets  containing  Ln/2J  random  numbers.  This  allows  us  to 
sign  any  one  of: 


B„  = 


[n  /  2  J 


(1) 


distinct  messages,  i.e.,  we  are  able  to  sign  an  arbitrary  (log  Bn)-bit  message. 

For  example,  if  R  contains  four  elements  1,  2,  3,  and  4,  then  the  largest  valid  message 
set  of  R  is: 
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V  =  {{1,2},  {1,3},  {1,4},  {2,  3},  {2,  4},  {3,  4}} 

which  contains  B4  =  6  elements.  By  inverting  this  formula,  using  Stirling’s 
approximation  and  taking  the  base  2  log  of  both  sides,  we  can  see  that  to  represent  2b 
distinct  values,  n  must  satisfy 


n  -  log  Vn«/2  >  b  (2) 

For  b  =  128  (e.g.,  MD5),  n  must  be  at  least  132,  and  each  subset  can  be  as  small  as 
size  64,  since  C(132,64)  >  2128.  For  b=160  (e.g.,  SHA1),  n  must  be  at  least  165 
(n  =  164  is  just  barely  insufficient),  with  subsets  of  size  75.  Note  that  we  can  freely 
increase  n  and  decrease  p,  or  similarly,  decrease  n  and  increase  p,  as  long  as  C(n,p)  > 
2b.  In  Figure  1,  we  show  the  number  of  random  numbers  n  versus  the  number  of 
hashes  required  for  verification  p,  for  two  popular  message  (digest)  sizes. 


Figure  1:  Signature  generatim  /verification  hash  prciile. 

3  Cost  Analysis  of  a  Single  One-Time  Signature 

3.1  All  On-line  Case 

In  the  preceding  sections,  we  showed  how  to  sign  an  arbitrary  b-bit  message  using  p 
of  n  random  numbers.  In  this  section,  we  will  describe  how  to  choose  n  and  p  to 
minimize  the  total  cost  of  a  one-time  signature.  Our  initial  assumption  is  that  all  of  the 
signing  process  is  performed  on-line,  once  the  message  is  presented. 

The  principal  cost  of  generating  a  one-time  signature  (aside  from  the  cost  of  securely 
distributing  the  anchor  values  H(R)  is  the  cost  of  computing  H(R);  this  costs  n  hashes. 
The  principal  cost  of  verifying  a  one-time  signature  (aside  from  the  cost  of  verifying 
the  anchor  values)  is  the  cost  of  computing  H(S);  this  costs  p  hashes.  However,  only 
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a  single  sender  generates  a  one-time  signature,  while  potentially  many  receivers 
verify  it.  Thus,  each  hash  involved  in  signature  verification  incurs  a  greater  cost  than 
one  involved  in  signature  generation. 


In  general,  let  each  verification  hash  cost  o  times  as  much  as  a  generation  hash.  The 
total  cost  of  a  single  signature  is  then  proportional  to  n+op;  this  is  the  quantity  that  we 
shall  try  to  minimize,  subject  to  the  condition  that  Cfn.p)  >  2b.  We  want  to  find  n  and 
p  such  that  C(n,p)  ~  C(n+o,p-l).  As  a  first  approximation,  we  have,  from  the 
definition  of  the  binomial  coefficient 

^  „  _  n 

(3) 


n  —  p 


n  —  p 


If  we  let  a  =  p/n,  we  have 


a  =  (l-a)CT+l 


(4) 


To  find  the  optimal  n  and  p,  we  find  the  p  such  that  C(LocpJ.p)  >  2b. 

3.2  On-line/Off-line  Case 

In  [2],  the  authors  introduce  the  new  concept  of  on-line/off-line  digital  signature 
schemes.  In  these  schemes  the  signing  of  a  message  is  broken  into  two  phases.  The 
first  phase  is  off-line.  Though  it  requires  a  moderate  amount  of  computation,  it 
presents  the  advantage  that  it  can  be  performed  at  leisure,  before  the  message  to  be 
signed  is  even  known.  The  second  phase  is  on-line  and  it  starts  after  the  message 
becomes  known.  Since  it  utilizes  the  precomputation  of  the  first  phase,  it  is  much 
faster. 

We  observe  that  the  signer  can  generate  the  vector  R={R1,...,Rn}  of  n  random 
numbers  and  by  applying  the  OWF  to  each  random  number,  he  can  generate  the 
hashes  off-line.  The  on-line  phase  is  just  a  mapping  and  at  costs  less  than  one  MD5 
hash  operation.  So,  in  this  case  we  try  to  minimize  the  verification  time.  This  is  also 
due  to  the  fact  that  many  times  only  a  single  sender  generates  an  OTS,  but  potentially 
many  receivers  verify  it. 

It  is  improper  to  take  the  verification  time  as  only  the  time  needed  to  make  the 
mapping  and  generate  the  hashes  of  the  random  numbers.  One  of  the  disadvantages  of 
OTS  is  its  length;  especially  if  we  have  a  low  bandwidth  channel,  the  time  needed  to 
transmit  the  signature  dominates  the  time  for  verification  and  cannot  be  neglected. 
Also  both  available  bandwidth  and  computation  power  vary  in  a  wide  range.  We 
therefore  need  to  decide  on  the  values  of  n  and  p  with  respect  to  bandwidth  and 
computation  power. 

Now,  we  will  describe  how  to  choose  n  and  p  to  minimize  the  total  time  T  needed  to 
verify  one  OTS.  Let’s  take  the  hash  length  as  b  and  random  number  length  as  a. 
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Assume  a  bandwidth  of  K  bits/sec.  And  L  seconds  as  the  time  required  to  perform  one 
hash  operation.  Then 


K 


(5) 


In  the  above  formula,  we  ignore  other  delays  such  as  queuing  delays.  One  extra  L  is 
for  generating  the  hash  of  the  message  and  m  is  the  time  for  the  mapping.  The  total 
time  needed  to  verify  one  OTS  is  then  proportional  to  n+op  where  o  =  (a  +  LK)  /  b. 
Fortunately,  this  is  the  same  quantity  we  have  tried  to  minimize  in  the  preceding 
subsection.  So  in  this  case  we  can  also  use  the  results  we  have  obtained  previously. 


4  Amortized  Cost  of  Many  Signatures 

Using  the  one-time  signature  only  once  is  inefficient,  since  the  sender  needs  to  sign 
the  original  hash  image  H(R)  using  a  conventional  digital  signature  (e.g.,  DSS). 
Using  a  tree  scheme,  as  in  Merkle  [6],  we  can  sign  an  arbitrarily  large  number  of 
messages  with  only  one  conventional  signature.  However,  the  incremental  cost  of 
generating  and  verifying  an  additional  signature  increases  logarithmically  with  the 
number  of  signatures. 

In  the  tree  scheme,  one  constructs  a  tree  of  signature  nodes.  Each  signature  node  has 
a  vector  for  signing  each  of  its  children  as  well  as  a  single  message.  The  root  node  is 
signed  by  conventional  means— i.e.,  using  a  digital  signature  key.  In  this  treatment, 
we  consider  only  a  binary  tree,  so  that  each  node  has  three  vectors.  Suppose  that  we 
choose  n  and  p  such  that  C(n,p)>2b.  We  would  like  to  compute  the  cost,  in  hashes,  of 
generating  and  verifying  a  signature  at  any  given  depth  d. 

To  generate  the  signature,  one  needs  to  do  a  one-time  signature  of  the  message 
(requiring  n  hashes).  Assuming  the  signer  can  cache  the  tree,  no  further  computation 
is  required.  Verification  requires  one  to  perform  p  hashes  to  verify  the  current  node’s 
signature  of  the  message,  and  additional  p  hashes  to  verify  the  parent  node’s  signature 
of  the  current  node.  If  the  receiver  has  cached  the  tree,  no  further  computation  is 
required;  otherwise,  an  additional  (d-l)p  hashes  are  required. 

In  contrast  to  the  single  signature  case,  then,  each  of  a  sequence  of  signatures  costs 
n+2p  hashes  if  receivers  cache  the  signature  tree,  or  n+(d+l)p  hashes  if  they  do  not. 
How  reasonable  is  it  to  cache  a  signature  tree?  If  we  choose  SHA  as  our  message 
digest,  we  need  to  sign  160  bits  of  message,  for  which  we  could  choose  n=165  and 
p=82.  Both  signer  and  verifier  must  cache,  for  each  node,  3n  160-bit  numbers  (the 
signer  caches  the  random  numbers  R,  then  verifier  caches  the  anchor  values  H(R)); 
this  works  out  to  4950  bytes  per  node.  This  is  easily  supported. 

In  fact,  receivers  who  cache  the  tree  need  only  maintain  the  lowest  layer  of  nodes,  so 
that  only  about  half  the  nodes  already  traversed  need  be  kept  at  any  time.  They  can 
prune  additional  information  off  the  tree  by  removing  the  message  signature  vectors 
after  they  are  exhausted. 
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5  Constructing  the  Optimal  Tree 

In  Section  4,  we  showed  how  to  choose  n  and  p  to  minimize  the  total  cost  of  an  OTS. 
Now  in  this  section  we  will  describe  how  to  choose  the  parameters  of  a  k-ary  tree 
with  a  depth  of  d.  Note  that  the  tree  structure  does  not  need  to  be  binary;  we  can 
increase  k.  On  the  other  hand  we  should  stop  somewhere  in  our  tree;  that  is  at  some 
point  the  cost  of  using  our  large  tree  to  verify  an  OTS  is  more  than  that  of  starting  a 
new  tree  in  which  we  have  signed  the  root  node  by  conventional  means.  In  other 
words,  we  need  to  optimize  the  value  of  d. 

We  will  try  to  minimize  the  average  verification  cost  of  one  OTS.  Suppose  that  the 
verifier  only  caches  the  root  node  of  the  tree.  This  is  a  reasonable  assumption, 
especially  when  the  signer  uses  the  tree  to  sign  messages  for  different  receivers. 
Suppose  also  that  the  cost  of  verifying  a  traditional  signature  is  C  times  more  than 
verifying  a  OTS.  In  a  k-ary  tree  with  a  depth  of  d,  the  number  of  messages  that 
can  be  signed  and  the  number  of  OTS  required  are 

d  d 

tdky~'iyky~l 

y=l  y=l 

respectively.  In  a  single  tree,  the  cost  per  message  is 

-1 

■v=l 

d 

y=l 

We  try  to  find  the  smallest  d  such  that  the  average  cost  per  message 
is  smaller  than  it  is  for  d+1.  If  we  use  the  equality  of 


w  =  Y,yky~' 

V=1 


1  -kd  -dkd  +dkd+l 
(k~  l)2 


d+ 1 

C  +  ^yk"-1 

y= 1 
d+ 1 

XV-1 

y=l 


C  +  £yky -1 

y=l 

d 

i*’-' 

y=l 


is  approximately  equal  to 
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C  +  (d  +  l)kd  +  W  ~  k(C  +  W) 

If  we  put  W  into  its  place  and  make  necessary  manipulations,  our  formula  becomes 

logfr-p’c  +  l],, 

log  k 


Figure  2:  choosing  the  optimal  depth  for  a  binary  tree 


In  Figure  2,  we  show  the  depth  of  a  binary  tree  versus  average  normalized  verification 
cost  per  message.  One  should  choose  the  depth  d  where  the  average  normalized  cost 
per  message  is  minimal. 


6  Conclusion 

We  have  provided  a  theoretical  foundation  for  evaluating  the  efficiency  and 
compactness  of  one-time  digital  signatures.  This  work  reveals  the  absolute  minimum 
complexity  of  computing  a  digital  signature  over  a  space  of  b-bit  messages,  based  on 
the  weighted  costs  of  signature  generation  and  verification.  We  have  shown  how 
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this  theoretical  minimum  can  be  achieved,  by  using  a  simple  and  efficient  mapping 
between  messages  and  subsets  of  random  numbers.  We  have  demonstrated  how  this 
family  of  one-time  signature  schemes  fits  into  an  elegant  protocol  for  amortizing  the 
cost  of  one-time  signatures  over  many  messages.  Finally,  we  have  provided  a 
theoretical  foundation  for  evaluating  the  efficiency  of  the  OTS  tree  structure  based  on 
the  weighted  costs  of  traditional  and  one-time  signatures. 
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Abstract.  Mediated  RSA  (mRSA)  [1]  is  a  simple  and  practical  method 
of  splitting  RSA  private  keys  between  the  user  and  the  Security  Medi¬ 
ator  (SEM).  Neither  the  user  nor  the  SEM  can  cheat  each  other  since  a 
signature  or  a  decryption  must  involve  both  parties.  mRSA  allows  fast 
and  fine-grained  control  (revocation)  of  users’  security  priviliges. 
Forward  security  is  an  important  and  desirable  feature  for  signature 
schemes.  Despite  some  notable  recent  results,  no  forward-secure  RSA 
variant  has  been  developed.  In  this  paper  (abstract),  we  show  how  weak 
forward  security  can  be  efficiently  obtained  with  mediated  RSA.  We  con¬ 
sider  several  methods,  based  on  both  multiplicative  and  additive  mRSA 
and  discuss  their  respective  merits. 


1  Forward  Security 

Forward  security  is  a  timely  and  active  research  topic  which  has  received  some 
attention  in  the  recent  research  literature.  The  purpose  of  forward  security  is 
to  mitigate  an  important  problem  in  ordinary  public  key  signatures:  the  inabil¬ 
ity  to  preserve  the  validity  of  past  signatures  following  a  compromise  of  one’s 
private  key.  In  other  words,  if  a  forward-secure  signature  scheme  is  employed, 
an  adversary  who  discovers  the  private  key  of  a  user  is  unable  to  forge  user’s 
signatures  from  earlier  times  (pre-dating  the  compromise). 

The  notion  of  forward  security  was  introduced  by  Anderson  [2].  Since  then, 
a  number  of  schemes  were  proposed.  Some  are  generic,  i.e.,  applicable  to  any 
signature  scheme  [3],  while  others  target  (and  modify)  a  particular  signature 
scheme  to  achieve  forward  security  [4,  5]. 

In  this  paper  we  concentrate  on  weak  forward  security  in  a  mediated  signature 
setting.  Informally,  weak  forward  security  means  that  the  adversary  is  unable  to 
forge  past  signatures  if  she  compromises  only  one  (of  the  two)  share-holders  of 
the  private  key.  Specifically,  we  propose,  discuss  and  analyze  two  simple  schemes 
built  on  top  of  mediated  RSA  (mRSA),  a  2-out-of-2  threshold  RSA  scheme. 

The  paper  is  organized  as  follows:  the  next  section  provides  an  overview 
of  mRSA.  Then,  Section  3  describes  the  forward  secure  additive  mRSA  and 
discusses  its  security  and  efficiency  features.  Section  4  presents  another  scheme 
based  on  multiplicative  mRSA.  This  scheme  is  more  flexible  but  slightly  less 
efficient.  The  paper  ends  with  the  summary  and  some  directions  for  future  work. 
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2  Mediated  RSA 


Mediated  RSA  (mRSA)  involves  a  special  entity,  called  a  SEM  (SEcurity  Media¬ 
tor)  which  is  an  on-line  semi-trusted  server.  To  sign  or  decrypt  a  message,  Alice 
must  first  obtain  a  message-specific  token  from  the  SEM.  Without  this  token 
Alice  can  not  use  her  private  key.  To  revoke  Alice’s  ability  to  sign  or  decrypt, 
the  administrator  instructs  the  SEM  to  stop  issuing  tokens  for  Alice’s  public  key. 
At  that  instant,  Alice’s  signature  and/or  decryption  capabilities  are  revoked.  For 
scalability  reasons,  a  single  SEM  serves  many  users.  One  of  the  rnRSA’s  advan¬ 
tages  is  its  transparency:  SEM’s  presence  is  invisible  to  other  users:  in  signature 
mode,  mRSA  yields  standard  RSA  signatures,  while  in  decryption  mode,  mRSA 
accepts  plain  RSA-encrypted  messages. 

The  main  idea  behind  mRSA  is  the  splitting  of  an  RSA  private  key  into  two 
parts  as  in  threshold  RSA  [6].  One  part  is  given  to  a  user  while  the  other  is 
given  to  a  SEM.  If  the  user  and  the  SEM  cooperate,  they  employ  their  respec¬ 
tive  half- keys  in  a  way  that  is  functionally  equivalent  to  (and  indistinguishable 
from)  standard  RSA.  The  fact  that  the  private  key  is  not  held  in  its  entirety 
by  any  one  party  is  transparent  to  the  outside,  i.e. ,  to  the  those  who  use  the 
corresponding  public  key.  Also,  knowledge  of  a  half-key  cannot  be  used  to  derive 
the  entire  private  key.  Therefore,  neither  the  user  nor  the  SEM  can  decrypt  or 
sign  a  message  without  mutual  consent. 

We  now  provide  an  overview  of  mRSA  functions.  The  variant  described  below 
is  the  additive  mRSA  (+mRSA)  as  presented  by  Boneh,  et  al.  in  [1].  There  is 
also  a  multiplicative  mRSA  variant  -  denoted  *mRSA  -  where  the  private  key  is 
computed  as  the  product  of  the  two  shares.  (See  Appendix  for  the  description). 
Muliplicative  mRSA  was  first  introduced  in  the  Yaksha  system  [7]  and  later 
discussed  in  [8]. 


Algorithm  tmRSA.key  (executed  by  CA) 
Let  k  (even)  be  the  security  parameter 

1.  Generate  random  k/ 2-bit  primes:  p,  q 

2.  n  «—  pq 

3.  e  t-  Z^(n) 

4.  d  <—  l/emod/>(n) 

5.  du  4-  Zn  -  {0} 

6.  dsem  «—  {d  —  du)  mod  <j>(n) 

7.  SK  <-  d 

8.  PK  t—  (n,  e) 


After  computing  the  above  values,  the  CA  securely  communicates  dsem  to 
the  SEM  and  du  -  to  the  user.  (A  detailed  description  of  this  procedure  can  be 
found  in  [1].)  The  user’s  public  key  PK  is  released,  as  usual,  in  a  public  key 
certificate. 


141 


Protocol  +mRSA.sign  (executed  by  User  and  SEM) 

1.  USER:  h  <-  H(m) 

where  HQ  is  a  suitable  hash  function  (e.g.,  SHA-based  HMAC)  and 
1^01  <*• 

2.  USER:  send  h  to  SEM. 

3.  In  parallel: 

3.1  SEM: 

(a)  If  USER  revoked  return  (ERROR) 

(b)  PSsem  <—  hd“’n  mod  n 

(c)  send  PSsem  to  USER 

3.2  USER: 

(a)  PSU  <—  hdu  mod  n 

4.  USER:  h!  <r-  {PSsem  *PSu)e  mod  n 

5.  USER:  If  ti  ±  h  then  return  (ERROR) 

6 ■  S  <—  {PSsem  *  PSu)  mod  n 

7.  USER:  return  (h,S) 


The  signature  verification  (+mRSA.ver)  algorithm  is  not  provided  as  it  is  iden¬ 
tical  to  that  in  plain  RSA. 

3  Forward  Secure  +mRSA 

The  main  idea  in  forward-secure  additive  rnRSA  (FS+mRSA)  is  for  both  SEM 
and  user  to  evolve  their  private  key  shares  in  parallel.  The  evolution  is  very 
simple:  each  party  logically  multiplies  its  share  by  e.  We  say  “logically”  since 
no  actual  muliplication  is  performed;  instead,  each  party  merely  maintains  a 
counter  (i)  which  is  the  index  of  the  current  time  period.  As  in  all  other  forward 
secure  schemes,  there  is  a  maximum  number  T  past  which  the  shares  are  not 
evolved. 

At  any  given  time,  the  current  private  key  is: 

di  =  do  *  e‘  and  do  =  d*e~T 

The  user’s  and  SEM’s  respective  key  shares,  at  a  given  interval  are: 

di,u  =  (do, u)  *  e*  where  do, it  =  du  *  e~T  mod  <f>(n) 

and: 

dl,sem  =  (d0,«em)  *  e*  where  d0,sem  =  dsem  *  e~T  mod  <j>(n) 

The  j-tli  private  key  evolution  can  be  thus  rewritten  as: 

di  =  (d0,u)  *  e*  +  (d0,«em)  *  e‘  =  d0  *  e‘  =  d  *  el~T 

In  actuality,  both  user  and  SEM  always  maintain  do,u  and  do,sem,  which  are 
their  respective  initial  shares.  However,  when  they  apply  their  respective  shares 
(to  sign  a  message)  they  use  the  current  evolution.  The  reason  for  not  actually 
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computing  d.^u/sem  is  because  neither  the  SEM  nor  the  user  knows  <f>{n)  and 
thus  cannot  compute  values  of  the  form: 


(  {do,u/sem)  *e‘)  mod  <j>(n) 


Recall  that  p,  q  and,  consequently,  (f>(n)  are  known  only  to  the  CA. 

The  flavor  of  forward  security  offered  by  our  approach  is  weak.  Here  ’weak’ 
means  that,  throughout  the  lifetime  of  the  public  key  (T  periods),  the  adversary 
is  allowed  to  compromise  only  one  of  the  parties’  secrets,  i.e. ,  only  dijU  or  ditSem 
but  not  both. 

Although  the  above  may  be  viewed  as  a  drawback,  we  claim  that  weak  for¬ 
ward  security  is  appropriate  for  the  rnRSA  setting,  since  the  security  of  mRSA 
is  based  on  the  non-compromise  of  both  key  shares.  More  specifically,  the  SEM  is 
an  entity  more  physically  secure  and  more  trusted  than  a  regular  user.  Hence,  it 
makes  sense  to  consider  what  it  takes  for  rnRSA  to  be  forward  secure  primarily 
with  respect  to  the  user’s  private  key  share. 


3.1  FS+mRSA  in  detail 


Like  most  forward-secure  signature  methods,  FS+mRSA  is  composed  of  the  fol¬ 
lowing  four  algorithms:  FS+mRSA .  key ,  FS+mRSA .  sign  FS+mRSA .  ver  and  FS+mRSA .  update. 
The  purpose  of  the  first  three  is  obvious,  while  FS+mRSA. update  is  the  secret 
key  share  update  algorithm  executed  by  both  user  and  SEM.  We  do  not  spec¬ 
ify  FS+mRSA. update  since  it  is  trivial:  as  mentioned  above,  it  does  not  actually 
evolve  each  party’s  key  share:  it  merely  increments  the  interval  counter. 


Algorithm  FS+mRSA. key  (executed  by  CA) 

Let  (t,  T)  be  the  length  of  the  update  interval  and  the  max. 
number  of  update  intervals,  respectively. 

1-7.  Identical  to  +mRSA.key 

8.  PK  <—  (t,  T,  n,  e) 

9.  do,u  +-  du  *  e~T  mod  <f>(n) 

10.  d'O'Sem  ^  dsem  ^  C  mod 
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Protocol  FS+mRSA.sign  (i,m) 

i  (0  <  i  <  T)  is  the  current  interval  index  and  m  is  the 

input  message 

1.  USER:  h  <-  H,(m) 

where  Hi( )  is  a  suitable  hash  function  (e.g.,  SHA-based  HMAC)  in¬ 
dexed  with  the  current  interval.  (|-ffi()|  <  k ) 

2.  USER:  send  m  to  SEM. 

3.  In  parallel: 

3.1.  SEM: 

(a)  If  USER  revoked  return  (ERROR) 

(b)  h  <r-  Hi (m) 

(c)  PSsem  <-  [hd°’3em)ei  mod  n 

(d)  send  PSsem  to  USER 

3.2.  USER: 

(a)  PSU  <—  ( hd°'u)c  mod  n 

4.  USER :h'  <-  (PSsem  *  PSu)e*eT~'  mod  n 

5.  USER:  If  ti  ^  h  then  return  (ERROR) 

6.  S  <—  ( PSsem  *  PSu)  mod  n 

7.  USER:  return  (h,S) 


We  note  that,  in  steps  3.1. a,  3.2.b  and  4,  two  exponentiations  are  performed. 

Algorithm  FS+mRSA.ver  (i,S,m,e,n) 
i (0  <  i  <  T)  is  the  claimed  interval  index, 

S  is  the  purported  signature  on  a  message  m,  and  (e,  n)  is  the 
public  key  of  the  signer 

1.  if  (i  <  0)  or  (i  >  T)  return  (ERROR) 

2.  h  t—  Hi(mn) 

3.  ti  <r-  Se*eT~i 

4.  If  ti  h  then  return  (0) 

5.  return  (1) 


From  the  descriptions  of  FS+mRSA.sign  and  FS+mRSA.ver  it  is  clear  that 
the  present  scheme  is  correct,  i.e.,  signature  verification  succeeds  iff  a  valid  sig¬ 
nature  is  provided: 

^ - m  _  j-^du*e~T -\-dsem^e~T _  ^d*ei  —  T 


and 


=  (ti 


d*e% 


^e*e 


=  hed  =  h 


3.2  Efficiency 

In  [1] ,  the  efficiency  of  mRS A  is  shown  to  be  roughly  equivalent  to  unoptimized 
RSA,  i.e.,  RSA  without  using  the  Chinese  Remainder  Theorem  (CRT).  The 
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efficiency  of  FS+mRSA  is  only  slightly  lower  than  that  of  mRSA.  The  only 
difference  in  signing  is  the  extra  exponentiation  with  e'  performed  by  both  the 
user  and  the  SEM  in  parallel. 

In  general,  an  additional  exponentiation  with  el  is  also  needed  for  verifying 
FS+mRSA  signatures.  However,  we  observe  that,  if  the  user’s  public  exponent 
is  small  (e.g.,  3),  the  curent  public  key  e*  =  3*+1  is  likely  to  be  smaller  than  the 
modulus  n  for  many  values  of  i.  For  example,  if  e  =  3  and  k  =  1024,  N  <  k 
and  e.j  <  n  for  0  <  i  <  592.  In  that  case,  e*  can  be  stored  as  a  single  k  —  bit 
number  and  only  one  exponentiation  would  be  required  to  verify  an  FS+mRSA 
signature. 

The  extra  storage  due  to  forward  security  in  FS+mRSA  is  negligible.  Since 
key  shares  are  only  logically  evolved,  the  only  extra  information  maintained  by 
all  signers  and  SEM-s  (on  top  of  what  is  already  required  by  mRSA)  is  the  index 
of  the  current  time  interval. 


3.3  Security  Considerations 

In  all  security  aspects  (other  than  forward  security)  the  proposed  scheme  is 
essentially  equivalent  to  plain  RSA  as  argued  in  [1].  Similarly,  the  forward  se¬ 
curity  property  of  FS+mRSA  is  based  on  the  difficulty  of  computing  roots  in  a 
composite-order  group  which  is  also  the  foundation  of  the  RSA  cryptosystem. 
While  this  extended  abstract  does  not  contain  a  proof  of  this  claim,  we  provide 
the  following  informal  argument: 

Assume  that  the  adversary  compromises  the  user  at  an  interval  j  and, 
as  a  result,  learns  do.u-1  In  order  to  violate  forward  security,  it  suffices 
for  the  adversary  to  generate  a  single  new  signature  of  the  form  (where 
i  <  j  and  h  =  H(m )  for  some  new  message  m): 

S  =  hdi  =  hd°’’e'  =  hd°-^m’re'+d°-'‘*e‘  =  (hd *hd°-u*e‘) 

Computing  hd (  mod  n)  is  trivial.  However,  computing  hd (  mod 
n)  seems  to  require  taking  e-th  (cube)  roots  (modn)  since,  in  the  cur¬ 
rent  interval  j  (j  >  i),  the  SEM  is  using  as  its  key  share  (do, sew  *  eJ)  and 
only  “produces”  values  of  the  form:  hd mod  n. 

All  forward-secure  signature  schemes  proposed  thus  far  rely  on  the  secure 
deletion  of  old  secret  keys.  This  is  not  always  a  realistic  assumption,  especially 
when  secure  (tamper-resistant)  hardware  is  not  readily  avaialable.  In  this  aspect, 
FS+mRSA  offers  an  advantage  since  the  user’s  secret  key  share  is  not  actually 
evolved  and  no  deletion  of  prior  secrets  is  assumed.  While  the  compromise  of 
the  user’s  current  key  share  yields  all  user’s  key  shares  for  all  prior  intervals, 
no  past-dated  signatures  can  be  produced  since  the  SEM’s  key  share  evolves 
separately.  We  also  note  that  this  property  is  symmetric:  if  a  SEM’s  key  share 

1  This  is  possible  because  dj,u  is  never  actually  computed,  but  composed,  when  needed, 
as  do,u  *  eJ . 
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is  ever  compromised,  forward  security  is  preserved  as  long  as  the  user’s  share 
remains  secure. 

There  are,  however,  two  types  of  attacks  unique  to  FS+mRSA.  We  refer 
to  the  first  type  as  a  future-dating  attack.  In  it,  an  adversary  obtains  a  valid 
signature  from  the  user  ( m,S )  under  the  current  public  key  ( e,n,i ).  He  then 
takes  advantage  of  the  private  key  structure  to  construct  a  valid  signature  (S’) 
on  the  same  message  m  dated  in  some  future  interval  j  (i  <  j  <  T).  This  can 
be  easily  done  by  computing: 

C*l  _  geJ~'  _  |^fdu+dse7ll)*ei_TjeJ_’  _  j^d*e^~T 

We  note  that  this  attack  does  not  compromise  the  forward  security  property  of 
the  signature  scheme.  However,  it  does  pose  a  problem  for  FS+mRSA.  Fortu¬ 
nately,  there  is  an  easy  fix.  It  involves  hashing  the  index  of  the  current  time 
interval  together  with  the  message.  This  is  already  specified  in  the  initial  step 
in  protocol  FS+mRSA.  sign.  (In  other  words,  instead  of  h  =  H(m)  we  can  com¬ 
pute  h  =  or,  better  yet,  h  =  HMACj(m).  This  essentially  rules  out  the 

future-dating  attack.) 

The  second  attack  type  is  an  oracle  attack.  In  it,  an  adversary,  masquarading 
as  the  user,  sends  signature  requests  to  the  SEM  during  the  time  interval  i. 
This  is  easy  to  do  since  the  communication  channel  between  the  user  and  the 
SEM  is  neither  private  nor  authentic.  The  adversary  collects  a  number  of  “half¬ 
signatures”  of  the  form  (■ m,PSsem )  where: 


Suppose  that  at  a  later  interval  j  (i  <  j  <  T),  the  adversary  actually  com¬ 
promises  the  user’s  secret  djtU.  Although  the  adversary  can  not  compute  “new” 
signatures  from  prior  time  intervals,  he  can  use  the  previously  acquired  half¬ 
signatures  to  forge  signatures  from  period  i: 


S'  =  ( PSi<sem ) 


du*e ' 


=  ( hd 


=  h 


d*e 


One  simple  way  of  coping  with  the  oracle  attack  is  to  require  the  user-SEM 
communication  channel  to  be  authentic.  This  is  not  much  of  a  burden  in  practice 
due  to  widely-deployed  and  available  tools  such  as  IPSec  [9]  and  SSL  [10].  An 
alternative  is  to  require  mRSA-based  authentication  of  the  signature  request 
messages  flowing  from  the  user  to  the  SEM.  This  can  be  accomplished  as  follows. 
When  sending  a  signature  request  to  the  SEM,  the  user  computes,  in  addition: 
h  =  H(h )  where  HQ  ^  HQ  is  a  suitable  (cryptographically  strong)  hash 
function  such  that  |Ff()|  <  k.  He  then  computes: 

PSU  <-  hd°’u  mod  n 


The  user  sends  PSU  along  with  h  in  the  signature  request  to  the  SEM.  The 
SEM,  before  computing  its  half-signature  ( PSsem ),  verifies  PSU  by  computing: 
hJ  =  H{h)  and  comparing: 

h'  and  (PSV/0’""")6*6  mod  n 
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Since  these  two  values  match  only  if  the  user  originated  the  signature  request 
oracle  attacks  can  be  thereby  avoided. 


4  Forward  Secure  *mRSA 


We  now  construct  another  forward-secure  scheme  based  on  the  multiplicative 
rnRSA  variant.  Only  the  key  generation  and  signing  algorithms  are  shown;  the 
verification  algorithm  is  identical  to  that  in  FS+mRSA. 

Algorithm  FS*mRSA.key 

.-7.  Identical  to  *mRSA.key  (see  Appendix) 

8.  PK  <  (t.  T,  n.  e) 

9.  do.sem  t  dsem  t  C  mod  (fi{'Tl) 


The  main  difference  with  respect  to  FS  +  mRSA  is  the  unilateral  update 
feature.  In  the  present  scheme,  only  the  SEM’s  share  is  evolved  whereas  the  user’s 
share  remains  the  same  throughout  the  lifetime  of  the  key.  This  is  a  desireable 
feature  since  it  saves  the  user  one  exponentiation  over  FS+mRSA.  However,  this 
does  not  significantly  influence  the  overall  performance  since,  unlike  FS+mRSA, 
the  two  parties  cannot  compute  their  half-signatures  in  parallel. 


Protocol  FS*mRSA.sign 


1.  USER:  h  Hi(m ) 

2.  USER:  send  m  to  SEM 

3.  SEM:  If  USER  revoked  return  (ERROR) 

4.  SEM:  h  <  II A  in) 

5.  SEM:  PSSem  <—  hdi’‘em  mod  n 

6.  SEM:  send  PSsem  to  USER 

7.  USER:  ti  <-  ( PSdcumY’eT~ '  mod  n 

8.  USER:  If  ti  ±  h  then  return  (ERROR) 

9.  S  {PSsem)  mod  n 
10.  USER:  return  (h,S) 


The  correctness  of  FS*mRSA  is  evident  from  the  verification  procedure: 


(sy 


=  ((pssem)dye 


—  ,sem  'jdu 


^hdse,n*e’  Tyuy*eT  ‘  =  ^d* e ;  Ty*eT  ‘  = 

Just  like  FS+mRSA,  this  scheme  is  vulnerable  to  both  future-dating  and 
oracle  attacks.  Fortunately,  the  exact  countermeasures  described  in  Section  3.3 
are  equally  applicable  here. 

Another  trivial  variation  of  this  scheme  entails  only  the  user  (but  not  the 
SEM)  evolving  its  key  share.  This  is  a  less  attractive  option  since  it  is  much  more 
likely  that  the  user,  rather  than  the  SEM,  succumbs  to  eventual  compromise. 
Finally,  it  is  also  possible  to  have  both  parties  evolving  the  key  (just  as  in 
FS+mRSA) .  The  main  difference  here  would  be  that  signature  verification  would 
require  an  extra  exponentiation  with  e2i  rather  than  e*. 
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5  A  Final  Observation 


A  crucial  (but  purposely  ignored  above)  detail  in  the  construction  of  FS+mRSA 
and  FS*mRSA  is  the  use  of  the  current  period  index  i  in  the  hashing  of  the 
input  message.  The  intended  purpose  of  the  index  is  as  a  hedge  against  possible 
attacks  against  the  key  evolution  scheme.  However,  a  closer  look  indicates  that 
the  inclusion  of  the  index  in  the  hash  is  in  and  of  itself  sufficient  to  provide  the 
same  weak  forward  security  that  we  hope  to  attain  with  key  evolution.  In  this 
case,  key  evolution  as  described  above  can  be  dropped  completely  to  be  replaced 
by  the  simple  hashing  of  the  period  index.  (This  would  also  result  in  a  much 
more  efficient  scheme.) 

6  Summary 

We  described  two  methods  of  obtaining  efficient  (yet  weak)  forward  security 
with  mediated  RSA.  These  methods  work  with  both  multiplicative  and  additive 
rnRSA  variants.  The  degree  of  forward  security  is  weak  since  we  assume  that 
only  the  user  or  the  SEM  (but  not  both)  are  compromised  by  the  adversary. 
However,  this  assumption  is  in  line  with  the  mRSA  notion  of  security  which  is 
based  on  the  inability  to  compromise  both  parties. 

Since,  aside  from  signatures,  mRSA  can  be  used  for  encryption,  the  natural 
issue  to  consider  is  whether  FS+mRSA  and  FS*mRSA  schemes  are  useful  for 
forward-secure  encryption. 
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A  Multiplicative  mRSA  -  *mRSA 

The  *mRSA  variant  is  largely  similar  to  its  additive  counterpart.  The  only  sub¬ 
stantive  difference  has  to  do  with  parallelizing  private  key  operations  by  the  user 
and  the  SEM.  In  +mRSA,  both  parties  can  perform  exponentiations  with  their 
respective  private  key  shares  in  parallel.  In  contrast,  *mRSA  prescribes  serial 
operation. 


Algorithm  tmRSA.key  (executed  by  CA) 
Let  k  (even)  be  the  security  parameter 

1.  Generate  random  A: /2-bit  primes:  p,  q 

2.  n  «—  pq 

3.  e  t-  z^(n) 

4.  d  <—  1/e  mod  <j>(n) 

5.  dy  t—  ^(n) 

6.  dsem  «—  {d/dy)  mod  <j>(n) 

7.  SK  <-  (d,n) 

8.  PK  e-  (n,e) _ 


As  in  additive  mRSA,  CA  securely  communicates  dsem  to  the  SEM  and  du 
-  to  the  user.  The  user’s  public  key  PK  is  released  as  part  of  a  public  key 
certificate. 


Protocol  *mRSA.sign  (executed  by  User  and  SEM) 


1.  USER:  h  <-  H{m ) 

2.  USER:  send  h  to  SEM 

3.  SEM:  If  USER  revoked  return  (ERROR) 

4.  SEM:  PSsem  <—  hd‘cm  mod  n 

5.  SEM:  send  PSscm  to  USER 

6.  USER:  h'  <-  ( PSdscumy  mod  n 

7.  USER:  If  h!  /  h  then  return  (ERROR) 

8.  USER:  S  <r-  ( PSdcum )  mod  n 

9.  USER:  return  (h,S) 
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Abstract 

We  introduce  a  short  signature  scheme  based  on  the  Computational  Diffie-Hellman  assump¬ 
tion  on  certain  elliptic  and  hyper-elliptic  curves.  For  standard  security  parameters,  the  signature 
length  is  about  half  that  of  a  DSA  signature  with  a  similar  level  of  security.  Our  short  signature 
scheme  is  designed  for  systems  where  signatures  are  typed  in  by  a  human  or  are  sent  over  a 
low-bandwidth  channel.  We  survey  a  number  of  properties  of  our  signature  scheme  such  as 
signature  aggregation  and  batch  verification. 


1  Introduction 

Short  digital  signatures  are  needed  in  environments  with  strong  bandwidth  constraints.  For  ex¬ 
ample,  product  registration  systems  often  ask  users  to  key  in  a  signature  provided  on  a  CD  label. 
When  a  human  is  asked  to  type  in  a  digital  signature,  the  shortest  possible  signature  is  needed. 
Similarly,  due  to  space  constraints,  short  signatures  are  needed  when  one  prints  a  bar-coded  digital 
signature  on  a  postage  stamp  [47,  42],  As  a  third  example,  consider  legacy  protocols  that  allocate 
a  fixed  short  field  for  non-repudiation  [1,  29].  One  would  like  to  use  the  most  secure  signature  that 
fits  in  the  alloted  field  length. 

The  two  most  frequently  used  signatures  schemes,  RSA  and  DSA,  produce  relatively  long  sig¬ 
natures  compared  to  the  security  they  provide.  For  example,  when  one  uses  a  1024-bit  modulus, 
RSA  signatures  are  1024  bits  long.  Similarly,  when  one  uses  a  1024-bit  modulus,  standard  DSA 
signatures  are  320  bits  long.  Elliptic  curve  variants  of  DSA,  such  as  ECDSA,  are  also  320  bits 
long  [2].  A  320-bit  signature  is  too  long  to  be  keyed  in  by  a  human. 

We  propose  a  signature  scheme  whose  length  is  approximately  170  bits  and  which  provides  a 
level  of  security  similar  to  that  of  320-bit  DSA  signatures.  Our  signature  scheme  is  secure  against 
existential  forgery  under  a  chosen-message  attack  (in  the  random  oracle  model),  assuming  the 
Computational  Diffie-Hellman  problem  (CDH)  is  hard  on  certain  elliptic  curves  over  a  finite  field. 
Generating  a  signature  is  a  simple  multiplication  on  the  curve.  Verifying  the  signature  is  done 
using  a  bilinear  pairing  on  the  curve.  Our  signature  scheme  inherently  uses  properties  of  curves. 
Consequently,  there  is  no  equivalent  of  our  scheme  in  F*,  the  multiplicative  group  of  a  finite  field. 

Constructing  short  signatures  is  an  old  problem.  Several  proposals  show  how  to  shorten  DSA 
while  preserving  the  same  level  of  security.  Naccache  and  Stern  [42]  propose  a  variant  of  DSA 
where  the  signature  length  is  approximately  240  bits.  Mironov  [40]  suggests  a  DSA  variant  with 
a  similar  length  and  gives  a  concrete  security  analysis  of  the  construction  in  the  random  oracle 
model.  Another  technique  proposed  for  reducing  DSA  signature  length  is  signatures  with  message 
recovery  [43,  47].  In  such  systems  one  encodes  a  part  of  the  message  into  the  signature  thus 


150 


shortening  the  total  length  of  the  message-signature  pair.  For  long  messages,  one  can  then  achieve 
a  DSA  signature  overhead  of  160  bits.  However,  for  very  short  messages  (e.g.,  64  bits)  the  total 
length  remains  320  bits.  Using  our  signature  scheme,  the  signature  length  is  always  on  the  order 
of  160  bits,  however  short  the  message.  We  also  note  that  Patarin  et  al.  [45,  18]  construct  short 
signatures  whose  security  depends  on  the  Hidden  Field  Equation  problem. 

Our  signature  scheme  uses  groups  where  the  CDH  problem  is  hard,  but  the  Decision  Diffie- 
Hellman  problem  (DDH)  is  easy.  The  first  example  of  such  groups  was  given  in  [31]  and  was  used 
in  [30,  10].  We  call  such  groups  Gap  Diffie- Heilman  groups,  or  GDH  groups  for  short.  We  show  how 
to  construct  a  signature  scheme  from  GDH  groups,  prove  security  of  the  scheme,  and  show  how  to 
build  GDH  groups  that  lead  to  short  signatures.  The  signature  scheme  resembles  the  undeniable 
signature  scheme  of  Chaurn  and  Pedersen  [14].  Our  signature  scheme  has  several  useful  properties, 
described  in  Section  5.  For  example,  signatures  generated  by  different  people  on  different  messages 
can  be  aggregated  into  a  single  signature  [11].  The  signature  also  supports  standard  extensions 
such  as  threshold  signatures  and  blind  signatures  [9]. 

Notation.  We  use  E/¥q  to  denote  an  elliptic  curve  with  coefficients  in  ¥q.  For  r  >  1,  we  use 
E(¥qr)  to  denote  the  group  of  points  on  E  in  ¥qr.  We  use  |£'(Fqr)|  to  denote  the  number  of  points 
in  E(¥qr). 

2  Gap  Diffie-Hellman  groups  and  bilinear  maps 

Before  presenting  the  signature  scheme,  we  first  review  a  few  concepts  related  to  bilinear  maps  and 
Gap  Diffie-Hellman  groups.  We  use  the  following  notation: 

•  G i  and  G2  are  two  (multiplicative)  cyclic  groups  of  prime  order  p; 

•  g\  is  a  generator  of  G\  and  52  is  a  generator  of  G2; 

•  ip  is  an  isomorphism  from  G2  to  G 1,  with  ^(52)  =  gi',  and 

•  e  is  a  bilinear  map  e  :  Gi  x  G2  Gt- 

The  group  Gt  is  described  below.  One  can  set  G\  =  G2,  but  we  allow  for  the  more  general  case 
where  G±  7^  G2  so  that  we  can  take  advantage  of  certain  families  of  non-supersingular  elliptic  curves 
as  described  in  Section  4.3. 

The  proofs  of  security  require  an  efficiently  computable  isomorphism  ip  :  G2  —*  Gi.  When 
G 1  =  G2  and  51  =  52  one  could  take  ip  to  be  the  identity  map.  When  G\  /  G2  we  will  need  to 
describe  explicitly  an  efficiently  computable  isomorphism  ip  :  G2  — >  G\.  The  map  ip  is  essential  for 
security.  To  illustrate  this,  we  give  in  the  next  section  an  example  of  a  bilinear  map  that  engenders 
an  insecure  signature  scheme  precisely  because  'ip  does  not  exist. 

With  this  setup  we  obtain  natural  generalizations  of  the  CDH  and  DDH  problems: 

Computational  co-Diffie-Hellman  (co-CDH)  on  (Gi,^):  Given  52,52  ^  ^2  and  h  £  G\  as 

input,  compute  ha  £  G\ . 

Decision  co-Diffie-Hellman  (co-DDH)  on  (Gi,^):  Given  52, g%  £  G2  and  h,hb  £  G\  as  in¬ 
put,  output  yes  if  a  =  b  and  no  otherwise.  When  the  answer  is  yes  we  say  that  (52, 5f,  h,  ha) 
is  a  co-Diffie-Hellman  tuple. 
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When  G\  =  G2  these  problems  reduce  to  standard  CDH  and  DDH. 

Next  we  a  define  a  co-GDH  group  pair  to  be  a  pair  of  groups  (Gi,G2)  on  which  co-DDH  is 
easy  but  co-CDH  is  hard.  We  define  the  success  probability  of  an  algorithm  A  in  solving  the 
Computational  co-Diffie-Hellman  problem  on  (Gi,G2)  as 


Succ  co-CDH_4  =f  Pr  A(g2,g%,h)  =  k 


:  a 


R 


Zp,  h 


R 


G 1 


The  probability  is  over  the  uniform  random  choice  of  a  from  Zp  and  h  from  G\,  and  over  the  coin 
tosses  of  A.  We  say  that  an  algorithm  A  ( t ,  e)-breaks  Computational  co-Diffie-Hellman  on  (G 1,  G2) 
if  A  runs  in  time  at  most  t,  and  Succ  co-CDH_4  is  at  least  e.  Here  time  is  measured  according  to 
some  fixed  computational  model  —  say,  state  transitions  in  a  probabilistic  (oracle)  Turing  machine. 

Definition  2.1.  Two  groups  (G'i ,  G'2)  are  a  (r,  f,e)-Gap  co-Diffie-Hellman  group  pair  (co-GDH 
group  pair)  if  they  satisfy  the  following  properties: 

•  The  group  operation  on  both  Gi  and  G2  and  the  map  tp  from  G2  to  Gi  can  be  computed  in 
time  at  most  r. 


•  The  Decision  co-Diffie-Hellman  problem  on  (G'i,  G'2)  can  be  solved  in  time  at  most  r. 

•  No  algorithm  (f,  e)-breaks  Computational  co-Diffie-Hellman  on  (G^G^). 

When  (Gi,Gi)  is  a  (r,  t,  e)  co-GDH  group  pair  we  say  G\  is  a  (r,  f,  e)-Gap-Diffie-Hellman  group 
(GDH  group). 

Informally,  we  are  only  interested  in  co-GDH  group  pairs  where  r  is  sufficiently  small  so  that  the 
co-DDH  problem  has  an  efficient  solution,  but  t/e  is  sufficiently  large  so  that  the  co-CDH  problem 
is  intractable.  Currently,  the  only  examples  of  such  Gap  Diffie-Hellman  groups  arise  from  bilinear 
maps  [31].  We  briefly  define  bilinear  maps  and  show  how  they  give  GDH  groups.  It  is  possible  that 
other  constructions  for  useful  Gap  Diffie-Hellman  groups  exist. 

Let  G\  and  G'2  be  two  groups  as  above,  with  an  additional  group  Gt  such  that  |Gi|  =  |  G'2 1  = 
|Gt|-  A  bilinear  map  is  a  map  e  :  Gi  x  G2  — >  Gt  with  the  following  properties: 

•  Bilinear:  for  all  u  £  G\,v  €  G2  and  a,  6  G  Z,  e(ua,vb)  =  e(u,v)ab. 

•  Non-degenerate:  e(g\,g2)  /  1. 

Definition  2.2.  Two  order-p  groups  (Gi,G2)  are  a  (r,  t,  e)-bilinear  group  pair  if  they  satisfy  the 
following  properties: 

•  The  group  operation  on  both  Gi  and  G2  and  the  map  ip  from  G2  to  G\  can  be  computed  in 
time  at  most  r. 

•  A  group  Gt  of  order  p  and  a  bilinear  map  e  :  G\  x  G2  — ►  Gt  exist,  and  e  is  computable  in 
time  at  most  r. 

•  No  algorithm  (f,  e)-breaks  Computational  co-Diffie-Hellman  on  (Gi,G2). 

Joux  and  Nguyen  [31]  showed  that  an  efficiently-computable  bilinear  map  e  provides  an  algo¬ 
rithm  for  solving  the  Decision  co-Diffie-Hellman  problem  as  follows:  For  a  tuple  (g2,  g%  1  h,  hb )  where 
h  G  Gi  we  have 

a  =  b  mod  p  e(h,  g%)  =  e(hb,  52)  . 

Consequently,  if  two  groups  (Gi,  G2)  are  a  (r,  t,  e)-bilinear  group  pair,  then  they  are  also  a  (2 r,  t,  e)- 
co-GDH  group  pair.  The  converse  is  probably  not  true. 
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3  Signature  schemes  based  on  Gap  Diffie-Hellman  groups 


We  present  a  signature  scheme  that  works  on  any  Gap  co-Diffie-Hellman  group  pair  (GpG^).  We 
prove  security  of  the  scheme  and,  in  the  next  section,  show  how  it  leads  to  short  signatures.  The 
scheme  resembles  the  undeniable  signature  scheme  proposed  by  Chaurn  and  Pedersen  [14] .  Okamoto 
and  Pointcheval  [44]  briefly  note  that  gap  problems  can  give  rise  to  signature  schemes.  However, 
most  gap  problems  will  not  lead  to  short  signatures. 

Let  (Gi,G2)  be  (t,  e)-Gap  co-Diffie-Hellman  group  pair  where  |Gi|  =  (G^l  =  p.  A  signature  a 
is  an  element  of  G\ .  The  signature  scheme  comprises  three  algorithms,  Key  Gen,  Sign ,  and  Verify. 
It  makes  use  of  a  full-domain  hash  function  H  :  {0, 1}*  — >  G\.  The  security  analysis  views  H  as  a 
random  oracle  [7].  In  Section  3.2  we  weaken  the  requirement  on  the  hash  function  H. 

R, 

Key  generation.  Pick  random  x  <—  Zp  and  compute  v  <—  g%.  The  public  key  is  v  £  G2.  The 
private  key  is  x. 

Signing.  Given  a  private  key  x  £  Zp,  and  a  message  M  £  {0, 1}*,  compute  h  <—  H(M)  £  G\  and 
<7  <—  hx.  The  signature  is  a  £  G\. 

Verification.  Given  a  public  key  v  £  G2,  a  message  M  £  {0, 1}*,  and  a  signature  a  £  G 1,  compute 
h  <—  H(M)  £  G 1  and  verify  that  (g2,v,h,a)  is  a  valid  co-Diffie-Hellman  tuple.  If  so,  output 
valid;  if  not,  output  invalid. 

A  signature  is  a  single  element  of  G\ .  To  construct  short  signatures,  therefore,  we  need  co- 
GDH  group  pairs  where  elements  in  G\  have  a  short  representation.  We  construct  such  groups  in 
Section  4. 

3.1  Security 

We  prove  the  security  of  the  signature  scheme  against  existential  forgery  under  adaptive  chosen- 
message  attacks  in  the  random  oracle  model.  Existential  unforgeability  under  a  chosen  message 
attack  [28]  for  a  signature  scheme  ( KeyGen ,  Sign ,  and  Verify)  is  defined  using  the  following  game 
between  a  challenger  and  an  adversary  A: 

Setup.  The  challenger  runs  algorithm  KeyGen  to  obtain  a  public  key  PK  and  private  key  SK. 
The  adversary  A  is  given  PK. 

Queries.  Proceeding  adaptively,  A  requests  signatures  with  PK  on  at  most  qs  messages  of 
his  choice  Mi, . . . ,  Mqg  £  {0, 1}*.  The  challenger  responds  to  each  query  with  a  signature 
a i  =  Sign(SK,  Mf). 

Output.  Eventually,  A  outputs  a  pair  ( M,a )  and  wins  the  game  if  (1)  M  is  not  any  of 
Mi, . . . ,  Mqa,  and  (2)  Verify(PK ,  M,  a)  =  valid. 

We  define  AdvSigyj  to  be  the  probability  that  A  wins  in  the  above  game,  taken  over  the  coin  tosses 
of  KeyGen  and  of  A. 

Definition  3.1.  A  forger  A  (t,qs,qH,e)- breaks  a  signature  scheme  if  A  runs  in  time  at  most  t,  A 
makes  at  most  qs  signature  queries  and  at  most  qH  queries  to  the  hash  function,  and  AdvSigyj  is 
at  least  e.  A  signature  scheme  is  (t,  qs,  qH,  e)-existentially  unforgeable  under  an  adaptive  chosen- 
message  attack  if  no  forger  (t,  qs,  qH,  e)-breaks  it. 
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The  following  theorem  shows  that  the  signature  scheme  is  secure.  Security  of  the  scheme  follows 
from  the  hardness  of  co-CDH  on  (Gi,G2).  When  G±  =  G-2  security  is  based  on  the  standard 
Computational  Diffie-Hellman  assumption  in  G\ . 

Theorem  3.2.  Let  (Gi,^)  be  a  {r,t' ,e')-co-GDH  group  pair  of  order  p.  Then  the  signature 
scheme  on  (Gi,^)  is  ( t,qs,qH,e)-secure  against  existential  forgery  under  an  adaptive  chosen- 
message  attack  (in  the  random  oracle  model),  for  all  t  and  e  satisfying 

e>e(qs  +  l)-e'  and  t  <  t'  -  cGl(qH  +  2qs)  . 

Here  cGl  is  a  constant  that  depends  on  G\,  and  e  is  the  base  of  the  natural  logarithm. 

Proof.  Suppose  A  is  a  forger  algorithm  that  (t,  qs,  qH,  e)-breaks  the  signature  scheme.  We  show 
how  to  construct  a  f'-time  algorithm  B  that  solves  co-CDH  on  (Gi,G2)  with  probability  at  least 
e' .  This  will  contradict  the  fact  that  (Gi,G2)  is  a  (t' ,  e')-co-GDH  group  pair. 

Let  g2  be  a  generator  of  G 2.  Algorithm  B  is  given  g2,u  £  G 2  and  h  £  Gi,  where  u  =  gif.  Its 
goal  is  to  output  ha  £  Gi.  Algorithm  B  simulates  the  challenger  and  interacts  with  forger  A  as 
follows. 

Setup.  Algorithm  B  starts  by  giving  A  the  generator  <72  and  the  public  key  u  ■  gl)  £  G2,  where  r 
is  random  in  Zp. 

//-queries.  At  any  time  algorithm  A  can  query  the  random  oracle  H.  To  respond  to  these  queries 
algorithm  B  maintains  a  list  of  tuples  (Mj,  Wj,  bj,  Cj)  as  explained  below.  We  refer  to  this  list 
as  the  //-list.  The  list  is  initially  empty.  When  A  queries  the  oracle  H  at  a  point  Mj  £  {0, 1}*, 
algorithm  B  responds  as  follows: 

1.  If  the  query  Mj  already  appears  on  the  //-list  in  a  tuple  ( Mi,Wi ,  bi ,  Cj}  then  algorithm  B 
responds  with  L/(Mj)  =  wt  £  G\. 

2.  Otherwise,  B  generates  a  random  coin  c.L  £  {0, 1}  so  that  Pr[cj  =  0]  =  1  /(qs  +  1). 

3.  Algorithm  B  picks  a  random  bi  £  Zp  and  computes  Wi  <—  hl~Ci  ■  if(g2)bi  £  Gi. 

4.  Algorithm  B  adds  the  tuple  ( Mj,  Wj,  6j,  Cj )  to  the  //-list  and  responds  to  A  by  setting 
H(Mi)  =  Wi. 

Note  that  either  way  Wi  is  uniform  in  G\  and  is  independent  of  A’s  current  view  as  required. 

Signature  queries.  Let  Mj  be  a  signature  query  issued  by  A.  Algorithm  B  responds  to  this  query 
as  follows: 

1.  Algorithm  B  runs  the  above  algorithm  for  responding  to  //-queries  to  obtain  a  uq  £  G\ 
such  that  H(Mf)  =  Wi.  Let  (Mj,  w^,  bi,  cf)  be  the  corresponding  tuple  on  the  H- list.  If 
Cj  =  0  then  B  reports  failure  and  terminates. 

2.  Otherwise,  we  know  Cj  =  1  and  hence  Wi  =  if(g2)bi  £  Gi.  Define  ol  =  if(u)bi  ■  'f>(g2)rbi  £ 
Gi .  Observe  that  cr*  =  wf+r  and  therefore  cq  is  a  valid  signature  on  Mj  under  the  public 
key  u  ■  g 2  =  g)+r ■  Algorithm  B  gives  a j  to  algorithm  A. 

Output.  Eventually  algorithm  A  produces  a  message-signature  pair  ( Mf,crf )  such  that  no  signa¬ 
ture  query  was  issued  for  Mj.  If  there  is  no  tuple  on  the  H- list  containing  Mj  then  B  issues  a 
query  itself  for  H(Mf )  to  ensure  that  such  a  tuple  exists.  We  assume  <jf  is  a  valid  signature  on 
M f  under  the  given  public  key;  if  it  is  not,  B  reports  failure  and  terminates.  Next,  algorithm  B 
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finds  the  tuple  ( Mf,w,b,c }  on  the  H- list.  If  c  =  1  then  B  reports  failure  and  terminates. 
Otherwise,  c  =  0  and  therefore  H(Mf)  =  w  =  h-  ?/(g2)6.  Hence,  a  =  ha+r  ■  'ip(g-2)b('a+r'>  ■  Then 
B  outputs  the  required  ha  as  ha  <—  a/{hr  ■  'f>{u)b  ■  if{g2)rb)- 

This  completes  the  description  of  algorithm  B.  It  remains  to  show  that  B  solves  the  given  instance 
of  the  co-CDH  problem  on  ( Gri,G2 )  with  probability  at  least  eh  To  do  so,  we  analyze  the  three 
events  needed  for  B  to  succeed: 

£\:  B  does  not  abort  as  a  result  of  any  of  A’s  signature  queries. 

£2:  A  generates  a  valid  message-signature  forgery  (Mf,crf). 

£3:  Event  £2  occurs  and  c  =  0  for  the  tuple  containing  Mf  on  the  H- list. 

B  succeeds  if  all  of  these  events  happen.  The  probability  Pr[£i  A  £3]  is: 

Pr[£r  A  £3]  =  Pr[£i]  •  Pr[£2  |  £±]  ■  Pr[£3  |  £1  A  £2]  .  (1) 

The  following  claims  give  a  lower  bound  for  each  of  these  terms. 

Claim  1.  The  probability  that  algorithm  B  does  not  abort,  as  a  result  of  A’s  signature  queries  is  at 
least  1/e.  Hence,  Pr [£1]  >  1/e. 

Proof.  Without  loss  of  generality  we  assume  that  A  does  not  ask  for  the  signature  of  the  same 
message  twice.  We  prove  by  induction  that  after  A  makes  i  signature  queries  the  probability 
that  B  does  not  abort  is  at  least  (1  —  1  /(qs  +  1))*.  The  claim  is  trivially  true  for  i  =  0.  Let  Mi 
be  A’s  i’th  signature  query  and  let  ( Mi,Wi,bi,  Ci )  be  the  corresponding  tuple  on  the  H- list.  Then 
prior  to  issuing  the  query,  the  bit  Ci  is  independent  of  .A’s  view  —  the  only  value  that  could  be  given 
to  A  that  depends  on  Cj  is  but  the  distribution  on  H(Mf)  is  the  same  whether  q  =  0  or 

Ci  =  1.  Therefore,  the  probability  that  this  query  causes  B  to  abort  is  at  most  1  /(qs  +  1).  Using 
the  inductive  hypothesis  and  the  independence  of  Q,  the  probability  that  B  does  not  abort  after 
this  query  is  at  least  (1  —  1  /(qs  +  1))L  This  proves  the  inductive  claim.  Since  A  makes  at  most  qs 
signature  queries  the  probability  that  B  does  not  abort  as  a  result  of  all  the  signature  queries  is  at 
least  (1  —  1  /(qs  +  l))9s  >  1/e.  □ 

Claim  2.  If  algorithm  B  does  not  abort  as  a  result  of  A's  signature  queries  then  algorithm  A’s 
view  is  identical  to  its  view  in  the  real  attack.  Hence,  Pr[£2  |  £1]  >  e. 

Proof.  The  public  key  given  to  A  is  from  the  same  distribution  as  a  public  key  produced  by 
algorithm  KeyGen.  Responses  to  H-queries  are  as  in  the  real  attack  since  each  response  is  uniformly 
and  independently  distributed  in  G\ .  All  responses  to  signature  queries  are  valid.  Therefore,  A 
will  produce  a  valid  message-signature  pair  with  probability  at  least  e.  Hence,  Pr[£2  |  £1]  >  e.  □ 

Claim  3.  The  probability  that  algorithm  B  does  not  abort,  after  A  outputs  a  valid  forgery  is  at  least 
l/(qs  +  1).  Hence,  Pr[£3  |  £1  A  £2]  =  l/(qs  +  1). 

Proof.  Given  that  events  £1  and  £2  happened,  algorithm  B  will  abort  only  if  A  generates  a  forgery 
( Mf,af )  for  which  the  tuple  ( Mf,w,b,c }  on  the  H- list  has  c  =  1.  At  the  time  A  generates  its 
output  it  knows  the  value  of  c*  for  those  Mi  for  which  it  issued  a  signature  query.  All  the  remaining 
Cj’s  are  independent  of  A’s  view.  Indeed,  if  A  did  not  issue  a  signature  query  for  Mi  then  the 
only  value  given  to  A  that  depends  on  a  is  H(Mi),  but  the  distribution  on  H(Mi )  is  the  same 
whether  ct  =  0  or  ct  =  1.  Since  A  could  not  have  issued  a  signature  query  for  Mf  we  know  that  c 
is  independent  of  A’s  current  view  and  therefore  Pr[c  =  0  |  £1  A  £2]  =  1  /(qs  +  1)  as  required.  □ 
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Using  the  bounds  from  the  claims  above  in  equation  (1)  shows  that  23  produces  the  correct 
answer  with  probability  at  least  e/e{qs  +  1)  >  e'  as  required.  Algorithm  23’ s  running  time  is  the 
same  as  A’s  running  time  plus  the  time  it  takes  to  respond  to  ( qH+Qs )  hash  queries  and  qs  signature 
queries.  Each  query  requires  an  exponentiation  in  G\  which  we  assume  takes  time  cGl .  Hence,  the 
total  running  time  is  at  most  t  +  cGl(qH  +  2 qs)  <  t!  as  required.  This  completes  the  proof  of 
Theorem  3.2.  □ 

The  analysis  used  in  the  proof  of  Theorem  3.2  resembles  Coron’s  analysis  of  the  Full  Domain 
Hash  (FDH)  signature  scheme  [16].  We  note  that  the  security  analysis  can  be  made  tight  using 
Probabilistic  Full  Domain  Hash  (PFDH)  [17],  at  the  cost  of  increasing  signature  length.  The 
security  reduction  in  Theorem  3.2  can  also  be  made  tight  without  increasing  signature  length  via 
the  technique  of  Katz  and  Wang  [32] . 

Our  signature  scheme  requires  an  algorithm  for  deciding  DDH.  In  groups  where  a  DDH-deciding 
algorithm  is  not  available,  Goh  and  Jarecki  [27]  show  that  it  is  still  possible  to  construct  a  signature 
scheme  based  on  CDH,  at  the  cost  of  substantially  greater  signature  length. 

The  necessity  of  ip  :  G2  —■ ►  G\.  Recall  that  the  proof  of  security  relied  on  the  existence  of  an 
efficiently  computable  isomorphism  ip  :  G2  —■ <■  G\.  To  show  the  necessity  of  ip  we  give  an  example  of 
a  bilinear  map  e  :  G±  x  G2  — ■»  Gt  for  which  the  co-CDH  problem  is  believed  to  be  hard  on  (G 1,  G2) 
and  yet  the  resulting  signature  scheme  is  insecure. 

Let  q  be  a  prime  and  let  G2  be  a  subgroup  of  Z*  of  prime  order  p  with  generator  g.  Let  G\  be 
the  group  G\  =  Zp  with  addition.  Define  the  map  e  :  G\  x  G2  — >  G2  as  e(x,y)  =  yx.  The  map  is 
clearly  bilinear  since  e(ax,yb)  =  e(x,y)ab.  The  co-CDH  problem  on  (Gi,^)  is  as  follows:  Given 
g,ga  £  G2  and  x  £  G\  compute  ax  £  G\.  The  problem  is  believed  to  be  hard  since  an  algorithm 
for  computing  co-CDH  on  (G\,G<2)  gives  an  algorithm  for  computing  discrete  log  in  G2.  Hence, 
(Gi,G2)  satisfies  all  the  conditions  of  Theorem  3.2  except  that  there  is  no  known  computable 
isomorphism  ip  :  G2  —*  Gi.  It  is  is  easy  to  see  that  the  resulting  signature  scheme  from  this  bilinear 
map  is  insecure.  Given  one  message-signature  pair,  it  is  easy  to  recover  the  private  key. 

We  comment  that  one  can  avoid  using  ip  at  the  cost  of  making  a  stronger  complexity  assumption. 
Without  ip  the  necessary  assumption  for  proving  security  is  that  no  polynomial  time  algorithm  can 
compute  ha  £  G\  given  <72 , £  G2  and  gi,gf,h  £  G\.  Since  ip  naturally  exists  in  all  the  group 
pairs  (Gi,  G2)  we  are  considering,  there  is  no  reason  to  rely  on  this  stronger  complexity  assumption. 

3.2  Hashing  onto  elliptic  curves 

The  signature  scheme  needs  a  hash  function  H  :  {0, 1}*  — >  G\.  In  the  next  section  we  use  elliptic 
curves  to  construct  co-GDH  group  pairs  and  therefore  we  need  a  hash  function  H  :  {0, 1}*  — ►  G\ 
where  G\  is  a  subgroup  of  an  elliptic  curve.  Since  it  is  difficult  to  build  hash  functions  that  hash 
directly  onto  a  subgroup  of  an  elliptic  curve  we  slightly  relax  the  hashing  requirement. 

Let  F<j  be  a  field  of  characteristic  greater  than  2.  Let  E/¥q  be  an  elliptic  curve  defined  by 
y2  =  f(x)  and  let  E(¥q)  have  order  m.  Let  P  £  E{Fg)  be  a  point  of  prime  order  p.  where  p2 
does  not  divide  m.  We  wish  to  hash  onto  the  subgroup  G±  =  ( P ).  Suppose  we  are  given  a 
hash  function  H'  :  {0,1}*  — >  x  {0,1}.  Such  hash  functions  H'  can  be  built  from  standard 

cryptographic  hash  functions.  The  security  analysis  will  view  Hl  as  a  random  oracle.  We  use  the 
following  deterministic  algorithm  called  MapToGroup  to  hash  messages  in  {0, 1}*  onto  G\.  Fix  a 
small  parameter  I  =  [log2  log2(l/<5)] ,  where  5  is  some  desired  bound  on  the  failure  probability. 
MapToGroupH The  algorithm  defines  PI  :  {0, 1}*  — >  G\  as  follows: 
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1.  Given  A/  6  {0, 1}*,  set  i  <—  0; 

2.  Set  (x,  b)  <—  H'(i  ||  A/)  6  F?  x  {0, 1},  where  i  is  represented  as  an  /-bit  string; 

3.  If  f(x)  is  a  quadratic  residue  in  F9  then  do: 

3a.  Let  yo,  ]J\  6  Fg  be  the  two  square  roots  of  f{x).  We  use  b  G  {0, 1}  to  choose  between  these 
roots.  Choose  some  full  ordering  of  Fg  and  ensure  that  y\  is  greater  than  yo  according 
to  this  ordering  (swapping  yo  and  y\  if  necessary).  Set  Pm  G  E(¥q)  to  be  the  point 
Pm  =  ( x,yb )• 

3b.  Compute  Pm  =  ( m/p)PM ■  Then  Pm  is  in  G\.  If  Pm  /  O,  output  MapToGroupH,(M)  = 
Pm  and  stop;  otherwise,  continue  with  Step  4. 

4.  Otherwise,  increment  i.  and  go  to  Step  2;  if  i  reaches  21 ,  report  failure. 

The  failure  probability  can  be  made  arbitrarily  small  by  picking  an  appropriately  large  /.  For 
each  i,  the  probability  that  H'(i  ||  M)  leads  to  a  point  on  G\  is  approximately  1/2  (where  the 
probability  is  over  the  choice  of  the  random  oracle  H').  Hence,  the  expected  number  of  calls  to 
H'  is  approximately  2,  and  the  probability  that  a  given  message  M  will  be  found  unhashable  is 
l/2(21)  <  4'. 

Lemma  3.3.  Let  E/¥q  be  an  elliptic  curve  and  let  E(¥q)  have  order  m.  Let  G\  be  a  subgroup 
of  E(¥q)  of  order  p  such  that  p2  does  not  divide  m.  Suppose  the  co-GDH  signature  scheme  is 
(i,  qs,  qH,  e) -secure  in  the  groups  (G±,G2)  when  a  random  hash  function  H  :  {0, 1}*  — *  G i  is  used. 
Then  it  is  ( t  —  2 IcGlqH,  qH  ~  Qs  —  1,  qs,  e)- secure  when  the  hash  function  H  is  computed  with 
MapToGroupHi  and  H'  is  a  random  oracle  hash  function  H'  :  {0, 1}*  — >  Fg  x  {0, 1}.  Here  cGl  is  a 
constant  that  depends  on  G\ . 

Proof.  Suppose  a  forger  algorithm  P'  (t.  qH,  qs,  e)-breaks  the  co-GDH  signature  scheme  on  (G i,  G2) 
when  given  access  to  a  random  oracle  H'  :  {0, 1}*  — >  Fg  x  {0, 1}  and  MapToGroupHi.  We  build  an 
algorithm  P  that  (t  +  2IcGl(qH  +  qs  +  1),  qH  +  qs  +  1,  qs,  e)-breaks  the  co-GDH  signature  scheme 
when  given  access  to  a  full-domain  random  oracle  hash  H  :  {0, 1}*  — >  G\ . 

Setup.  To  respond  to  queries  made  by  P' .  P  uses  an  array  S{j ,  whose  entries  are  elements  of 
Fg  x  {0, 1}.  The  array  has  qH  rows  and  21  columns.  On  initialization,  P  fills  sij  with 
uniformly-selected  elements  of  Fg  x  {0, 1}. 

Algorithm  P  has  access  to  a  random  oracle  H  :  {0, 1}*  — >  G\.  It  will  use  this  to  simulate  the 
random  oracle  H'  :  {0, 1}*  ->  x  {0, 1}  that  P'  uses.  Algorithm  P  is  also  given  a  public 
key  v,  and  a  signing  oracle  for  that  key.  Its  goal  is  to  output  a  forgery  on  some  message 
under  v. 

Algorithm  P  runs  P'  and  responds  to  its  oracle  queries  as  follows. 

ZT-qiieries.  Algorithm  P  keeps  track  (and  indexes)  all  the  unique  messages  A/j  for  which  P' 
requests  an  H'  hash. 

When  P'  asks  for  an  H'  hash  of  a  message  w  ||  A/j  whose  Mi  the  forger  P  had  not  previously 
seen  (and  whose  w  is  an  arbitrary  /-bit  string),  P  must  fix  up  row  i  of  its  matrix  s  before 
responding. 

It  scans  the  row  s^,  0  <  j  <  21 .  For  each  entry  Sij  =  (x,  b),  P  follows  Step  3  of  MapToGroup, 
above,  seeking  points  in  G\  \  {O}.  If  none  of  the  entries  yields  a  point  in  G\  \  {O},  row  stj , 
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0  <  j  <  21 ,  is  not  patched.  Otherwise,  for  the  smallest  j  for  which  Sij  maps  into  G\  \  {O}, 
E  replaces  Sij  with  a  different  point  ( Xi,bi )  defined  as  follows.  Let  Qi  =  H(M/)  G  G ±.  If 
Qi  G  G\  \  O,  then  E  constructs  a  random  point  Qi  G  E(¥q)  satisfying  ( m/p)Qi  =  Qi  as 
follows: 

1.  Let  z  =  (m/p)^1  mod  p.  Note  that  m/p  is  integer  since  p  divides  m.  Furthermore,  m/p 
has  an  inverse  modulo  p  since  p2  does  not  divide  m  and  hence  m/p  is  relatively  prime 
to  p. 

2.  Pick  a  random  point  T*  G  E(¥q). 

3.  Set  Qi  =  (xi,  m)  =  pTi  +  zQi. 

Then  Qi  is  a  random  point  in  E(¥q)  such  that  ( m/p)Qi  =  Qi .  Algorithm  E  sets  =  (xi,  b/) 
where  bi  G  {0, 1}  is  set  so  that  ( Xi,bi )  maps  to  Qi  in  Step  3(a)  of  MapToGroup.  Note  that 
MapTo Group Hi (M/)  now  equals  H(M/),  and  that  the  distribution  of  is  not  changed  by 
the  patching. 

If  Qi  =  O.  then  xQt  =  Qj  =  O  for  all  x  G  Zp,  and  in  particular  for  the  private  key  x 
corresponding  to  the  challenge  public  key  v.  Algorithm  E  outputs  the  forgery  (Mi,  O)  and 
halts.  This  forgery  is  nontrivial  because  E  always  queries  its  H  oracle  at  a  message  Mi  before 
querying  its  signing  oracle  at  Mi. 

Once  this  preliminary  patching  has  been  completed,  E  is  able  to  answer  H'  hash  queries  by 
E'  for  strings  w  ||  Mi  by  simply  returning  SiW.  The  simulated  H'  which  E'  sees  is  perfectly 
indistinguishable  from  that  in  the  real  attack. 

Signature  queries.  Algorithm  E  is  asked  for  a  signature  on  some  message  Mi,  indexed  as  above. 
It  first  runs  its  H'  algorithm  above  to  fix  up  the  row  corresponding  to  Mt  in  its  s  matrix. 
This  computation  queries  the  H  oracle  at  Mj  and  may  cause  E  to  abort,  having  discovered 
a  trivial  forgery.  If  the  computation  does  not  abort,  MapToGroupH,(Mi)  =  H(M /)  holds. 
Algorithm  E  queries  its  own  signing  oracle  at  Mt ,  obtaining  a  signature  cq  G  G  \ ,  which  is 
also  the  correct  signature  under  the  MapToGroup hash  function.  Algorithm  E  responds  to 
the  query  with  u%. 

Output.  Finally,  E'  halts.  It  either  concedes  failure,  in  which  case  so  does  E ,  or  it  returns  a 
message  M*  and  a  nontrivial  forged  signature  a*.  Algorithm  E1  must  not  have  queried  its 
signing  oracle  at  M* ,  so  neither  did  E . 

Algorithm  E  first  runs  its  H'  algorithm  above  to  fix  up  the  row  corresponding  to  M*  in  its 
s  matrix.  This  assigns  to  M*  an  index  i* ,  such  that  Mi*  =  M* .  This  computation  queries 
the  H  oracle  at  M,;*  and  may  cause  E  to  abort,  having  discovered  a  trivial  forgery. 

If  the  computation  does  not  abort,  MapToGroup (M*)  =  H(M*)  holds.  Thus  o*  is  a  valid 
forgery  on  message  M*  under  hash  function  H  as  well  as  MapToGroupHi .  Since  E  did  not 
query  its  signing  oracle  at  M* ,  the  forgery  is  nontrivial  for  it  as  well  as  for  E' .  Algorithm  E 
outputs  the  valid  and  nontrivial  forgery  (M*,a*)  and  halts. 

Algorithm  E  succeeds  if  either  it  discovers  a  trivial  forgery  (a  message  M  such  that  H(M )  =  O) , 
or  it  perfectly  simulates  the  environment  that  E'  expects.  Whenever  E'  succeeds  in  creating  a 
nontrivial  forgery,  so  does  E.  If  E'  succeeds  with  probability  e,  so  does  E .  If  E'  takes  time  t 
to  run,  E  takes  time  t,  plus  the  s-array  fix-up  time  that  is  potentially  necessary  on  each  hash 
query,  each  signing  query,  and  at  the  final  output  phase.  If  running  the  exponentiation  in  Step  3 


158 


of  the  MapToGroup  algorithm  takes  time  cGl,  then  T  takes  time  at  most  t  +  2 IcGl(qH  +  qs  +  1). 
Algorithm  T  potentially  makes  a  hash  query  for  each  hash  query  made  by  J-\  for  each  signing 
query  made  by  J~' .  and  in  the  final  output  phase.  Algorithm  T  makes  a  signing  query  for  each 
signing  query  made  by  T' . 

Thus  if  T'  (t,  qH,  qs,  e)-breaks  the  co-GDH  signature  scheme  when  given  access  to  a  random 
oracle  H'  :  {0,1}*  — >  Fg  x  {0, 1}  and  Map  To  GroupH,,  then  T  (t+21  cGl(qH+qs+l),  qH+qs+l,  qs,  e)- 
breaks  the  co-GDH  signature  scheme  when  given  access  to  a  full-domain  random  oracle  hash  H  : 

{0, 1}*  — ►  G\. 

Conversely,  if  the  co-GDH  signature  scheme  is  (t,  qH,qs,  e)-secure  when  instantiated  with  a  full- 
domain  random  oracle  hash  H  :  {0, 1}*  — >  G  i,  it  is  (t  —  2IcGlqHl  qH~  Qs  ~  1,  Qs,  e)  when  instantiated 
with  a  random  oracle  H'  :  {0, 1}*  — >  F^  x  {0, 1}  and  MapToGroupH> .  □ 

4  Building  co-GDH  group  pairs  with  small  representations 

Using  the  Weil  [34,  pp.  243-245]  and  Tate  [21]  pairings,  we  obtain  co-GDH  group  pairs  from  certain 
elliptic  curves.  We  recall  some  necessary  facts  about  elliptic  curves  (see,  e.g.,  [34,  50]),  and  then 
show  how  to  use  certain  curves  for  short  signatures. 

4.1  Elliptic  curves  and  the  Weil  pairing 

Our  goal  is  to  construct  bilinear  groups  (GijG^)  which  lead  to  co-GDH  group  pairs  as  discussed 
in  Section  2.  Let  E/¥q  be  an  elliptic  curve.  We  first  define  a  useful  constant  called  the  security 
multiplier  of  a  subgroup  (P)  C  E(¥q). 

Definition  4.1.  Let  q  be  a  prime  power,  and  E/¥q  an  elliptic  curve  with  m  points  in  E(¥q).  Let 
P  in  E(¥q)  be  a  point  of  prime  order  p  where  p 2  {  m.  We  say  that  the  subgroup  (P)  has  a  security 
multiplier  a,  for  some  integer  a  >  0,  if  the  order  of  q  in  F*  is  a.  In  other  words: 

p  |  qa  —  1  and  p  \  qk  —  1  for  all  k  =  1,  2, . . . ,  a  —  1  . 

The  security  multiplier  of  E(¥q)  is  the  security  multiplier  of  the  largest  prime  order  subgroup  in 
E(¥q). 

We  describe  two  families  of  curves  that  provide  a  =  6.  For  standard  security  parameters  this  is 
sufficient  for  obtaining  short  signatures.  It  is  an  open  problem  to  build  useful  elliptic  curves  with 
slightly  higher  a,  say  a  =  10  (see  Section  4.5). 

Our  first  step  is  to  define  G\  and  G2.  We  will  then  describe  a  bilinear  map  e  :  G\  x  G2  — >  Gt, 
describe  an  isomorphism  ^  :  G*2  — *  G±,  and  discuss  the  intractability  of  co-CDH  on  (G 1,  G2). 

Balasubramanian-Koblitz.  Let  E/¥q  be  an  elliptic  curve  and  let  P  £  E(¥q)  be  a  point  of 
prime  order  p  with  p  \  q.  Suppose  the  subgroup  (P)  has  security  multiplier  a  >  1,  i.e.  p  \  q  —  1. 
Then,  a  useful  result  of  Balasubramanian  and  Koblitz  [3]  shows  that  E(¥qa)  contains  a  point  Q  of 
order  p  that  is  linearly  independent  of  P.  We  set  G\  =  (P)  and  G2  =  ( Q )■  Then  |Gi|  =  IG2I  =  p. 
Note  that  G\  C  E(¥q)  and  G-2  C  E(¥q<*). 

The  Weil  and  Tate  pairings.  With  notation  as  above,  let  E[p\  be  the  group  of  points  of  order 
dividing  p  in  E{Fqa ).  Then  the  group  E[p]  is  isomorphic  to  Zp  x  Zp  [50]  and  G\,G2  <  E\p\.  The 
Weil  pairing  is  a  map  e  :  E[p]  x  E[p\  — >  F*Q  with  the  following  properties: 
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(i)  Identity:  for  all  R  £  E\p],  e(R,  R)  =  1. 

(ii)  Bilinear:  for  all  R\,R-2  £  £?[p]  and  a,  b  £  Z  we  have  e(ai?i,  bR/2)  =  e(i?i,  R2)ab- 

(iii)  Non-degenerate:  if  for  i?  £  A[p]  we  have  e(R,  R')  =  1  for  all  R!  £  -E[p],  then  R  =  O.  It  follows 
that  e(P,  Q)  /  1. 

(iv)  Computable:  for  all  R\ ,  /?2  £  I£[p],  the  pairing  e(Ri,R-2)  can  be  computed  in  polynomial 
time  [39]. 

Note  that  e(i?i,  i?2)  =  1  if  and  only  if  and  R2  are  linearly  dependent.  See  [37,  10]  for  a  definition 
of  the  Weil  pairing  and  a  description  of  the  algorithm  for  computing  it.  The  Tate  pairing  [21]  is 
another  useful  bilinear  map  on  E \p\ .  It  has  properties  similar  to  those  of  the  Weil  pairing,  but  does 
not  necessarily  satisfy  Property  (i)  (identity). 

The  Weil  pairing  on  the  curve  E  induces  a  computable,  non-degenerate  bilinear  map  e  :  G 1  x 
G2  — >  F*a  which  enables  us  to  solve  the  Decision  co-Diffie-Hellman  problem  on  the  group  pair 
(Gi,  G 2).  When  the  Tate  pairing  induces  a  non-degenerate  map  on  G\  x  G2,  it  can  also  be  used  to 
solve  Decision  co-Diffie-Hellman  on  (fG\,G<2). 

The  trace  map.  We  present  a  computable  isomorphism  if  :  G2  — * ►  G±,  using  the  trace  map,  tr, 
which  sends  points  in  E(¥qc)  to  E(¥q).  Let  a\, ...  ,aa  be  the  Galois  maps  of  F q<*  over  ¥q.  Also, 
for  R  =  (x,y)  £  E(¥qa)  define  a i(R)  =  (cri(x),  cq(y)).  Then  the  trace  map  tr  :  E(¥qa)  — ►  E(¥q)  is 
defined  by: 

tr(i?)  =  H - h  aa(R)  . 

Proposition  4.2.  Let  P  £  E(¥q)  be  a  point  of  prime  order  p  /  q  and  let  (P)  have  security 
multiplier  a  >  1.  Let  Q  £  E(¥qc)  be  a  point  of  order  p  that  is  linearly  independent  of  P.  If 
tr(Q)  /  O  then  tr  is  an  isomorphism  from  (Q)  to  (P). 

Proof.  Suppose  R  £  E(¥q)  is  a  point  of  order  p.  If  R  is  not  in  (P)  then  P  and  R  generate  E[p\ 
and  therefore  E\p\  C  E(¥q).  It  follows  that  e(P,R)  £  F*  has  order  p  since  otherwise  e  would  be 
degenerate  on  E[p\.  But  since  a  >  1  we  know  that  p  does  not  divide  q  —  1  and  consequently  there 
are  no  elements  of  order  p  in  F*.  Hence,  we  must  have  R  £  (P).  It  follows  that  all  the  points  in 
E(¥q)  of  order  p  are  contained  in  ( P ).  Since  tr(Q)  /  O.  we  know  that  tr(Q)  £  E(¥q)  has  order  p 
and  therefore  tr(Q)  £  ( P ).  Hence,  tr  is  an  isomorphism  from  (Q)  to  (P) .  □ 

Hence,  when  tr(Q)  7^  O,  the  trace  map  is  an  isomorphism  from  G2  to  G\  and  is  computable  in 
polynomial  time  in  a  and  log  q  as  required. 

Intractability  of  co-CDH  on  (G 1,  G2).  The  remaining  question  is  the  difficulty  of  the  co-CDH 
problem  on  (G\,G2).  We  review  necessary  conditions  for  CDH  intractability.  The  best  known 
algorithm  for  solving  co-CDH  on  {G 1,  G2)  is  to  compute  discrete-log  in  G\ .  In  fact,  the  discrete-log 
and  CDH  problems  in  G±  are  known  to  be  computationally  equivalent  given  some  extra  information 
about  the  group  G±  [35].  Therefore,  it  suffices  to  consider  necessary  conditions  for  making  the 
discrete- log  problem  on  E(¥q)  intractable. 

Let  ( P )  be  a  subgroup  of  E(¥q)  of  order  p  with  security  multiplier  a.  We  briefly  discuss  two 
standard  ways  for  computing  discrete-log  in  ( P ). 
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1.  MOV:  Use  an  efficiently  computable  homomorphism,  as  in  the  MOV  reduction  [36],  to  map 

the  discrete  log  problem  in  (P)  to  a  discrete  log  problem  in  some  extension  of  Fg,  say  We 
then  solve  the  discrete  log  problem  in  F*,  using  the  Number  Field  Sieve  algorithm  [49].  The 
image  of  (P)  under  this  homomorphism  must  be  a  subgroup  of  F*,;  of  order  p.  Thus  we  have 
p\(ql  —  1),  which  by  the  definition  of  a  implies  that  i  >  a.  Hence,  the  MOV  method  can,  at 
best,  reduce  the  discrete  log  problem  in  ( P )  to  a  discrete  log  problem  in  a  subgroup  of  F*a. 
Therefore,  to  ensure  that  discrete  log  is  hard  in  (P)  we  want  curves  where  a  is  sufficiently 
large  to  make  discrete  log  in  F*a  intractable. 

2.  Generic:  Generic  discrete  log  algorithms  such  as  Baby-Step-Giant-Step  and  Pollard’s  Rho 

method  [38]  have  a  running  time  proportional  to  sjplogp.  Therefore,  we  must  ensure  that  p 
is  sufficiently  large. 

In  summary,  we  want  curves  E/¥q  where  both  a  generic  discrete  log  algorithm  in  E(¥q)  and 
the  Number  Field  Sieve  in  F*Q  are  intractable.  At  the  same  time,  since  our  signature  scheme  has 
signatures  of  length  [ log2  q]  and  public  keys  of  length  [ a  log2  q] ,  we  wish  to  keep  q  as  small  as 
possible. 

4.2  Co-GDH  signatures  from  elliptic  curves 

We  summarize  the  construction  for  co-GDH  group  pairs  and  adapt  the  signature  scheme  to  use  a 
group  of  points  on  an  elliptic  curve. 

The  co-GDH  group  pair  (G i,  G2)  we  use  is  defined  as  follows: 

1.  Let  E/Fq  be  an  elliptic  curve  and  let  P  G  E(¥q)  be  a  point  of  prime  order  p  where  p  \  q(q  —  1) 
and  p2  \  |H(Fq)|. 

2.  Let  a  >  1  be  the  security  multiplier  of  (P).  We  assume  a  <  p.  By  Balasubramanian  and 
Koblitz  [3]  there  exists  a  point  Q  G  E(¥qa )  that  is  linearly  independent  of  P.  It  is  easy  to 
construct  such  a  Q  in  expected  polynomial  time  once  the  number  of  points  in  E(¥qa)  is  known. 
Since  a  >  1  we  know  that  Q  0  E(Fq).  We  ensure  that  tr(Q)  /  O.  If  tr(Q)  =  O  replace  Q  by 
Q  +  P.  Then  Q  +  P  is  of  order  p,  it  is  linearly  independent  of  P,  and  tr(Q  +  P)  7^  O  since 
tr(P)  =  aP  /  O. 

3.  Set  G\  =  (P)  and  G2  =  (Q). 

4.  Since  P  and  Q  are  linearly  independent,  the  Weil  pairing  gives  a  non-degenerate  bilinear  map 
e  :  Gi  x  G2  — >  F*a.  It  can  be  computed  in  polynomial  time  in  a  and  logg.  When  the  Tate 
pairing  is  non-degenerate  on  G\  x  G2  it  can  also  be  used  as  a  bilinear  map. 

5.  Since  tr(Q)  7^  O  the  trace  map  on  E(Fqa)  is  an  isomorphism  from  G2  to  G\  computable  in 
polynomial  time  in  a  and  logq. 

With  these  subgroups  G\,G2  of  the  elliptic  curve  E/¥q  the  signature  scheme  works  as  follows. 
Recall  that  MapToGroupHi  is  a  hash  function  MapToGroupH,  :  {0,1}*  — >  G\  built  from  a  hash 
function  H'  :  {0, 1}*  — >  F*  x  {0, 1}  as  described  in  Section  3.2. 

Key  generation.  Pick  random  x  <—  Zp,  and  compute  V  <—  xQ.  The  public  key  is  V  G  E(Fqa). 
The  private  key  is  x. 

Signing.  Given  a  private  key  x  G  Zp,  and  a  message  M  G  {0, 1}*,  do: 
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1.  Compute  R  <—  MapToGroupH,(M )  G  G i, 

2.  a  <—  x.R  G  E(F?),  and 

3.  output  the  x-coordinate  of  a  as  the  signature  s  on  M.  Then  sG  ¥q. 

Verification.  Given  a  public  key  V  G  G2,  a  message  M  G  {0, 1}*,  and  a  signature  sGF?  do: 

1.  Find  a  y  G  ¥q  such  that  a  =  ( s,y )  is  a  point  in  E(¥q).  If  no  such  y  exists,  output 
invalid  and  stop. 

2.  Ensure  that  a  has  order  p.  If  it  does  not,  output  invalid  and  stop. 

3.  Compute  R  <—  Map  To  Group H,(M)  G  G±, 

4.  Test  if  either  e(<7,  Q)  =  e(R,  V )  or  e(a,  Q)_1  =  e(R,  V). 

If  so,  output  valid;  Otherwise,  output  invalid. 

The  signature  length  is  [~log2  q]  ■  Note  that  during  verification  we  accept  the  signature  if 
e(<r,  Q)~x  =  e(R,V).  This  is  to  account  for  the  fact  that  the  signature  s  G  F?  could  have  come 
from  either  the  point  a  or  — <7  in  E(¥q). 

Security.  By  Theorem  3.2  it  suffices  to  study  the  difficulty  of  co-CDH  on  (Gi,G2).  The  best 
known  algorithm  for  solving  the  co-CDH  problem  on  (Gi,  G2)  requires  the  computation  of  a  discrete 
log  in  Gi  or  the  computation  of  a  discrete  log  in  F*a . 

4.3  Using  non-supersingular  curves  over  fields  of  high  characteristic 

It  remains  to  build  elliptic  curves  with  the  desired  security  multiplier  a.  In  the  next  two  sections  we 
show  curves  with  security  multiplier,  a  =  6.  We  begin  by  describing  a  family  of  non-supersingular 
elliptic  curves  with  a  =  6.  This  family  is  outlined  by  Miyaji  et  al.  [41].  We  call  these  MNT  curves. 

The  idea  is  as  follows:  Suppose  q  =  (2£)2  +  1  and  p  =  (2£)2  —  2£  +  1  for  some  1g2.  Then  it 
can  be  verified  that  p  divides  qe  —  1,  but  does  not  divide  ql  —  1  for  0  <  i  <  6.  So,  when  p  is  prime, 
a  curve  E/¥q  with  p  points  is  likely  to  have  security  multiplier  a  =  6. 

To  build  E/¥q  with  p  points  as  above  we  use  complex  multiplication  [8,  chapter  VIII].  We  briefly 
explain  how  to  do  so.  Suppose  we  had  integers  y,  t  and  another  positive  integer  D  =  3  mod  4  such 
that 

q  =  (t2  +  Dy2)/ 4  (2) 

is  an  integer  prime.  Then  the  complex  multiplication  method  will  produce  an  elliptic  curve  E/¥q 
with  q  +  1  —  t  points  in  time  0(D2 (log  c/)3).  The  value  t  is  called  the  trace  of  the  curve. 

We  want  a  curve  over  ¥q  with  p  points  where  q  =  (2£)2  +  1  and  p  =  (2£)2  —  2^  +  1.  Therefore, 
t  =  q  +  1  —  p  =  2£+l.  Plugging  these  values  into  (2)  we  get  A((2£)2  +  1)  =  (2£  +  l)2  +  Dy 2  which 
leads  to: 

(6£  —  l)2  —  3Z)y2  =  —8  .  (3) 

For  a  fixed  D  =  3  mod  4,  we  need  integers  £,  y  satisfying  the  equation  above  such  that  q  =  (2£)2  + 1 
is  prime  and  p  =  (2£)2  —  2^+1  is  prime  (or  is  a  small  multiple  of  a  prime).  For  any  such  solution 
we  can  verify  that  we  get  a  curve  E(¥q)  with  security  multiplier  a  =  6.  Finding  integer  solutions 
£,  y  to  an  equation  of  type  (3)  is  done  by  reducing  it  to  Pell’s  equation,  whose  solution  is  well 
known  [51]. 
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Discriminant 

Signature  Size 

DLog  Security 

MOV  Security 

D 

[log2<?1 

fl°g  2  7*] 

[ 6  log2  q] 

13368643 

149 

149 

894 

254691883 

150 

147 

900 

8911723 

157 

157 

942 

62003 

159 

158 

954 

12574563 

161 

161 

966 

1807467 

163 

163 

978 

6785843 

168 

166 

1008 

28894627 

177 

177 

1062 

153855691 

185 

181 

1110 

658779 

199 

194 

1194 

1060147 

203 

203 

1218 

20902979 

204 

204 

1224 

9877443 

206 

206 

1236 

Table  1:  Non-supersingular  elliptic  curves  for  co-GDH  Signatures,  ill  is  a  curve  over  the  prime  field 
Fq  and  p  is  the  largest  prime  dividing  its  order.  The  MOV  reduction  maps  the  curve  onto  the  field 
¥q6.  D  is  the  discriminant  of  the  complex  multiplication  field  of  E/¥q. 

Table  1  gives  some  values  of  D  that  lead  to  suitable  curves  for  our  signature  scheme.  For 
example,  we  get  a  curve  E/¥q  where  q  is  a  168-bit  prime.  Signatures  using  this  curve  are  168-bits 
while  the  best  algorithm  for  co-CDH  on  E(¥q)  requires  either  (1)  a  generic  discrete  log  algorithm 
taking  time  approximately  283,  or  (2)  a  discrete  log  in  a  1008-bit  finite  field  of  large  characteristic. 


4.4  A  special  supersingular  curve 


Another  method  for  building  curves  with  security  multiplier  a  =  6  is  to  use  a  special  supersingular 
curve  E / F3.  Specifically,  we  use  the  curve  E  :  y2  =  x3  +  2x  ±  1  over  F3.  The  MOV  reduction  maps 
the  discrete  log  problem  in  E( F3<?)  to  F*6(,.  We  use  two  simple  lemmas  to  describe  the  behavior  of 
these  curves.  (See  also  [54,  33].) 


3^  +  1  +  V3  •  3e  when  £  =  ±1  mod  12,  and 
3£  +  1  —  VS  ■  3£  when  £  =  ±5  mod  12. 


Lemma  4.3.  The  curve  E+  defined  by  y2  =  x3  +  2x  +  1  over  F3  satisfies 

|£+(MI  =  | 

The  curve  E~  defined  by  y2  =  x3  +  2x  —  1  over  F3  satisfies 

|£"(MI  = 


3e  +  1  —  n/3  •  3£  when  £  =  ±  1  mod  12,  and 
3e  +  1  +  V3  ■  3e  when  £  =  ±5  mod  12. 


Proof.  See  [33,  Section  2], 


□ 


Lemma  4.4.  Let  E  be  an  elliptic  curve  defined  by  y2  =  x3  +  2x±  1  over  ¥:it. ,  where  £  mod  12  equals 
±1  or  ±5.  Then  |-F(F3<?)|  divides  36£  —  1. 


Proof.  See  [54], 


□ 
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Together,  Lemmas  4.3  and  4.4  show  that,  for  the  relevant  values  of  £,  groups  on  the  curves 
E+/¥3e  and  E~/¥3i  will  have  security  multiplier  a  at  most  6  (more  specifically:  a  |  6).  Whether 
the  security  parameter  actually  is  6  for  a  particular  prime  subgroup  of  a  curve  must  be  determined 
by  computation. 

Automorphism  of  E+,E~  /¥3m:  Both  curves  E+  and  E~  have  a  useful  automorphism  that 
make  the  prime-order  subgroups  of  -F+(F3<)  and  E~( F3«)  into  GDH  groups  (as  opposed  to  co-GDH 
group  pairs).  This  fact  can  be  used  to  shrink  the  size  of  the  public  key  since  it  makes  it  possible 
for  the  public  key  to  live  in  E(¥3e)  as  opposed  to  E( F36«). 

The  automorphism  is  defined  as  follows.  For  £  such  that  £  mod  12  is  ±1  or  ±5,  compute  three 
elements  of  F36«,  u,  r+,  and  r_,  satisfying  u 2  =  —1,  (r+)3  +  2r+  +  2  =  0,  and  (?’“)3  +  2 r-  —2  =  0. 
Now  consider  the  following  maps  over  F36«: 

4>+(x,y)  =  (—x  +  r+ ,uy)  and  4>~  (x,y)  =  (—x  +  r~  ,uy)  . 

Lemma  4.5.  Let  l  mod  12  equal  ±1  or  ±5.  Then  f>+  is  an  automorphism  of  E+/¥^t  and  4>~ 
is  an  automorphism  of  E~/ F36<?.  Moreover,  if  P  is  a  point  of  order  p  on  E+/¥3i  (or  on  E~/F3e) 
then  4>+(P)  (or  4>~(P))  is  a  point  of  order  p  that  is  linearly  independent  of  P. 

Proof.  See  Silverman  [50,  p.  326,  Case  II].  □ 

Let  E/¥3e  be  one  of  E+  or  E~  and  let  P  E  .E(F3*)  be  a  point  of  prime  order  p.  Set  G\  =  ( P ), 
the  group  generated  by  P.  Let  4>  :  E(¥3e)  — >  E(¥36t)  be  the  automorphism  of  the  curve  from  above. 
Define  the  modified  Weil  pairing  e  :  G\  x  G\  — >  F*6j,  as  follows:  e(P\,P2)  =  e(Pi,  f>(p2))  where  e 
is  the  standard  Weil  pairing  on  E\p].  By  Lemma  4.5  we  know  that  (j>(P)  is  linearly  independent 
of  P.  Therefore,  e  is  non-degenerate.  It  follows  that  G±  is  a  GDH  group;  4>  acts  as  a  distortion 
map  [53,  31].  This  has  two  implications  for  the  signature  scheme: 

•  Security  of  the  signature  scheme  is  based  on  the  difficulty  of  the  standard  Computational 
Diffie-Hellman  problem  in  G\  (as  opposed  to  the  co-CDH  problem). 

•  Public  keys  are  elements  of  G\  and,  hence,  are  shorter  than  public  keys  should  the  automor¬ 
phism  not  exist. 

Useful  curves.  Some  useful  instantiations  of  these  curves  are  presented  in  Table  2.  Note  that 
we  restrict  these  instantiations  to  those  where  £  is  prime,  to  avoid  Weil-descent  attacks  [24,  25], 
except  for  £  =  121.  It  has  recently  been  shown  that  certain  Weil-descent  attacks  are  not  effective 
for  this  case  [19]. 

Performance.  Galbraith  et  al.  [23]  and  Barreto  et  al.  [4]  show  that  the  Frobenius  map  on  the 
curves  E+,E~  can  be  used  to  speed  the  computation  of  the  Weil  and  Tate  pairings  on  these 
curves.  This  results  in  a  significant  speed-up  to  the  signature-verification  algorithm.  Consequently, 
the  signature  scheme  using  these  curves  is  much  faster  than  the  scheme  using  the  curves  from  the 
previous  section. 

The  bad  news.  MOV  reduces  the  discrete  log  problem  on  £V(F3f)  and  E~(F3e)  to  a  discrete 
log  problem  in  F*M.  A  discrete-log  algorithm  due  to  Coppersmith  [15,  49]  is  specifically  designed 
to  compute  discrete  log  in  small  characteristic  fields.  Consequently,  a  discrete-log  problem  in  F3„ 
is  much  easier  than  a  discrete-log  problem  in  F*  where  p  is  a  prime  of  approximately  the  same  size 


164 


curve 

l 

Sig  Size 
[log2  3£1 

DLog  Security 
flog  2P~\ 

MOV  Security 
[61og2  3*] 

E~ 

79 

126 

126 

752 

E+ 

97 

154 

151 

923 

E+ 

121 

192 

155 

1151 

E+ 

149 

237 

220 

1417 

E+ 

163 

259 

256 

1551 

E~ 

163 

259 

259 

1551 

E+ 

167 

265 

262 

1589 

Table  2:  Supersingular  elliptic  curves  for  GDH  signatures.  Here  p  is  the  largest  prime  divisor  of 
|-E’(F3«)|.  The  MOV  reduction  maps  the  curve  onto  a  field  of  characteristic  3  of  size  36£. 


as  3n.  To  get  security  equivalent  to  DSA  using  a  1024-bit  prime,  we  would  have  to  use  a  curve 
E(F3e)  where  36*  is  much  larger  than  1024  bits.  This  leads  to  much  longer  signatures,  defeating 
the  point  of  using  these  curves.  In  other  words,  for  a  fixed  signature  length,  these  supersingular 
curves  lead  to  a  signature  with  reduced  security  compared  to  the  curves  of  Section  4.3. 

4.5  An  open  problem:  higher  security  multipliers 

With  the  curves  of  Section  4.3,  a  security  multiplier  of  a  =  6  is  sufficient  for  constructing  short 
signatures  with  security  comparable  to  DSA  using  a  1024-bit  prime.  However,  to  obtain  security 
comparable  to  DSA  using  a  2048-bit  prime  with  a  =  6  we  get  signatures  of  length  2048/6  =  342 
bits.  Elliptic  curves  with  higher  a,  say  a  =  10,  would  result  in  short  signatures  when  higher  security 
is  needed  (such  as  2048-bit  discrete- log  security). 

Let  q  be  a  large  prime  power,  say,  q  >  2160.  It  is  currently  an  open  problem  to  construct  an 
elliptic  curve  E/¥q  such  that  E(¥q)  has  a  =  10  and  E(Fq)  has  prime  order.  Several  constructions  [5, 
20,  13]  show  how  to  build  elliptic  curves  E  such  that  E(¥q)  has  a  given  security  multiplier  a. 
However,  the  largest  prime  order  subgroup  of  E(¥q)  is  much  smaller  than  q.  For  example,  the 
constructions  of  [5,  20]  give  curves  E/¥q  where  the  largest  prime  factor  of  |E(Fg)|  is  of  order  ^Jq. 
Discrete  log  in  such  groups  takes  time  approximately  q1/4.  Therefore,  for  a  given  security  parameter, 
the  resulting  signatures  are  of  the  same  length  as  DSA  signatures.  The  constructions  in  [13]  give 
curves  where  the  largest  prime  factor  of  |£'(Fg)|  is  greater  than  q ,  but  still  substantially  smaller 
than  q.  These  curves  result  in  signatures  that  are  shorter  than  DSA,  but  longer  than  half  the  size 
of  DSA.  The  open  problem  is  to  build  elliptic  curves  E/¥q  with  a  given  security  multiplier  a  where 
E(Fq)  has  prime  order.  Such  curves  would  provide  signatures  that  are  half  the  size  of  DSA  for  any 
given  security  level. 

One  could  also  build  GDH  groups  of  higher  genus.  Galbraith  [22]  constructs  supersingular  curves 
of  higher  genus  with  a  “large”  security  multiplier.  For  example,  the  Jacobian  of  the  supersingular 
curve  y2  +  y  =  x5  +  x3  has  security  multiplier  12  over  ¥2e-  Since  a  point  on  the  Jacobian  of  this 
curve  of  genus  2  is  characterized  by  two  values  in  F2«  (the  two  x-coordinates  in  a  reduced  divisor), 
the  length  of  the  signature  is  2t  bits.  Hence,  we  might  obtain  a  signature  of  length  2(  where  the 
security  depends  on  computing  CDH  in  the  finite  field  ¥2i2t.  This  factor  of  6  between  the  length  of 
the  signature  and  the  degree  of  the  finite  field  is  the  same  as  in  the  elliptic  curve  case.  Hence,  this 
genus  2  curve  does  not  improve  the  security  of  the  signature,  but  does  give  more  variety  in  curves 
used  for  short  signatures.  Discrete  log  on  the  Jacobian  of  these  curves  is  reducible  to  discrete-log  in 
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a  field  of  characteristic  2  and  consequently  one  must  take  Coppersmith’s  discrete  log  algorithm  [15] 
into  account,  as  discussed  at  the  end  of  Section  4.4. 

To  obtain  larger  security  multipliers,  Rubin  and  Silverberg  [48]  propose  certain  Abelian  varieties. 
They  show  that  signatures  produced  using  the  curve  of  Section  4.4  can  be  shortened  by  20%.  The 
result  is  an  n-bit  signature  where  the  pairing  reduces  the  discrete  log  problem  to  a  finite  field  of 
size  approximately  27"5n.  This  is  the  only  useful  example  we  currently  know  of  where  the  multiplier 
is  greater  than  6. 

5  Extensions 

Our  signatures  support  threshold  signatures  and  batch  verification.  Surprisingly,  signatures  from 
distinct  people  on  distinct  messages  can  be  aggregated  into  a  single  convincing  signature.  We 
briefly  survey  these  extensions  here  and  refer  to  Boldyreva  [9],  Verheul  [52],  and  Boneh  et  al.  [11] 
for  a  full  description  and  proofs  of  security. 

5.1  Aggregate  signatures 

Common  environments  require  managing  many  signatures  by  different  parties  on  distinct  messages. 
For  example,  certificate  chains  contain  signatures  on  distinct  certificates  issued  by  various  Certifi¬ 
cate  Authorities.  Our  signature  scheme  enables  us  to  aggregate  multiple  signatures  by  distinct 
entities  on  distinct  messages  into  a  single  short  signature.  Any  party  that  has  all  the  signatures 
can  aggregate  signatures,  and  aggregation  can  be  done  incrementally:  Two  signatures  are  aggre¬ 
gated,  then  a  third  is  added  to  the  aggregate,  and  so  on.  See  [11]  for  more  applications. 

Let  (Gi,G2)  be  a  bilinear  group  pair  of  prime  order  p.  Suppose  n  users  each  have  a  public- 
private  key  pair.  For  i  =  1, . . . ,  n,  user  i  has  private  key  xt  £  Zp  and  public  key  Vi  =  g% 1  £  GV 
Suppose  user  i  signs  a  message  M%  £  {0, 1}*  to  obtain  the  signature  a  *  =  H(Mj)Xi  £  G\.  The 
aggregate  of  all  these  signatures  is  computed  simply  as  a  <—  aia-2  ■  ■  ■  crn  £  G\. 

Aggregate  verification:  We  are  given  all  public  keys  vi, . . . ,  vn  £  G2,  all  messages  Mi, ... ,  Mn  £ 
{0, 1}*,  and  the  aggregate  signature  a  £  G\.  To  verify  that,  for  all  i  =  1 ,n,  user  i  has  signed 
message  Mj,  we  test  that 

1.  The  messages  Mi, . . . ,  Mn  are  all  distinct,  and 

2.  e(a,g2)  =  TYi=ie(H(Mi),Vi). 

If  both  conditions  hold,  we  accept  the  aggregate  signature.  Otherwise,  we  reject. 

We  refer  to  [11]  for  the  exact  security  model  and  the  proof  of  security.  An  attacker  who  can 
existentially  forge  an  aggregate  signature  can  be  used  to  solve  co-CDH  on  (GijG^).  We  note 
that  aggregate  signature  verification  requires  a  bilinear  map  —  a  generic  Gap  Diffie-Hellman  group 
is  apparently  insufficient.  Generic  Gap  Diffie-Hellman  groups  are  sufficient  for  verifying  aggregate 
signatures  on  the  same  message  by  different  people,  or  for  verifying  aggregate  signatures  on  distinct 
messages  by  the  same  person. 

5.2  Batch  verification 

Suppose  n  users  all  sign  the  same  message  M  £  {0, 1}*.  We  obtain  n  signatures  a  1, . . . ,  on.  We 
show  that  these  n  signatures  can  be  verified  as  a  batch  much  faster  than  verifying  them  one  by 
one.  A  similar  property  holds  for  other  signature  schemes  [6]. 
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Let  (Gi,  G2)  be  a  co-GDH  group  pair  of  prime  order  p.  Suppose  user  i’s  private  key  is  Xi  G  Zp 
and  his  public  key  is  Vi  =  g^1  G  G2.  Signature  o%  is  o%  =  H(M)Xi  G  Gi.  To  verify  the  n  signatures 
as  a  batch  we  use  a  technique  due  to  Bellare  et  al.  [6] : 

1.  Pick  random  integers  ci, . . . ,  cn  from  the  range  [0,  B\  for  some  value  B.  This  B  controls  the 
error  probability  as  discussed  below. 

2.  Compute  V  <—  [J'Li  VT  £  G2  and  U  <—  n[Li  £  Gi. 

3.  Test  that  (g2,  V,  H(M),  U)  is  a  co-Diffie-Hellman  tuple.  Accept  all  n  signatures  if  so;  reject 
otherwise. 

Theorem  3.3  of  [6]  shows  that  we  incorrectly  accept  the  n  signatures  with  probability  at  most 
1/B.  Hence,  verifying  the  n  signatures  as  a  batch  is  faster  than  verifying  them  one  by  one.  Note 
that  if  all  signers  are  required  to  prove  knowledge  of  their  private  keys,  then  taking  c\  =  ■  ■  ■  =  cn  =  1 
is  sufficient,  yielding  even  faster  batch  verification  [9].  A  similar  batch  verification  procedure  can 
be  used  to  verify  quickly  n  signatures  on  distinct  messages  issued  by  the  same  public  key. 

5.3  Threshold  signatures 

Using  standard  secret  sharing  techniques  [38],  our  signature  scheme  gives  a  robust  f-out-of-n  thresh¬ 
old  signature  [9].  In  a  threshold  signature  scheme,  there  are  n  parties  where  each  possesses  a  share 
of  a  private  key.  Each  party  can  use  its  share  of  the  private  key  to  produce  a  share  of  a  signature 
on  some  message  M.  A  complete  signature  on  M  can  only  be  constructed  if  at  least  t  shares  of  the 
signature  are  available. 

A  robust  f-out-of-n  threshold  signature  scheme  derives  from  our  signature  scheme  as  follows. 
A  central  authority  generates  a  public/private  key  pair.  Let  x  G  be  the  private  key  and 
v  =  g%  G  G-2  be  the  public  key.  The  central  authority  picks  a  random  polynomial  u  G  Zp[X\  of 
degree  at  most  f  —  1  such  that  w(0)  =  x.  For  i  =  1, . . . ,  n,  the  authority  gives  user  i  the  value 
Xi  =  ca(i),  its  share  of  the  private  key.  The  authority  publishes  the  public  key  v  and  n  values 
Ui  =  g%  G  G2. 

When  a  signature  on  a  message  M  G  {0, 1}*  is  needed  each  party  that  wishes  to  participate  in 
signature  generation  publishes  its  share  of  the  signature  as  <Jl  =  H(M)Xi  G  Gi.  Without  loss  of 
generality,  assume  users  1, ...  ,t  participate  and  generate  shares  oq, . . . ,  at-  Anyone  can  verify  that 
share  <7,;  is  valid  by  checking  that  (g2,Ui,  H(M),ai)  is  a  co-Diffie-Hellman  tuple.  When  all  f  shares 
are  valid,  the  complete  signature  is  recovered  as 

(T  < —  TT  cqAi  where  A,;  =  - —  (mod  p)  . 

f=I  IWi(i-j) 

If  fewer  than  t  users  are  able  to  generate  a  signature  on  some  message  M  then  these  users  can 
be  used  to  solve  co-CDH  on  (Gi,G2)  [9].  This  threshold  scheme  is  robust:  A  participant  who 
contributes  a  bad  partial  signature  a%  will  be  detected  immediately  since  ( g2,Ui ,  H(M),  (Jj)  will  not 
be  a  co-Diffie-Hellman  tuple. 

We  note  that  there  is  no  need  for  a  trusted  third  party  to  generate  shares  of  the  private  key. 
The  n  users  can  generate  shares  of  the  private  key  without  the  help  of  a  trusted  third  party  using 
the  protocol  due  to  Gennaro  et  al.  [26] ,  which  is  a  modification  of  a  protocol  due  to  Pedersen  [46] . 
This  protocol  does  not  rely  on  the  difficulty  of  DDH  for  security  and  can  thus  be  employed  on  Gap 
Diffie-Hellman  groups. 
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6  Conclusions 


We  presented  a  short  signature  based  on  bilinear  maps  on  elliptic  curves.  A  signature  is  only 
one  element  in  a  finite  field.  Standard  signatures  based  on  discrete  log  such  as  DSA  require  two 
elements.  Our  signatures  are  much  shorter  than  all  current  variants  of  DSA  for  the  same  security. 
We  showed  that  the  scheme  is  existentially  unforgeable  under  a  chosen  message  attack  (in  the 
random  oracle  model),  assuming  the  Computational  Diffie- Heilman  problem  is  hard  on  certain 
elliptic-curve  groups.  More  generally,  the  signature  scheme  can  be  instantiated  on  any  Gap  Diffie- 
Hellman  group  or  co-GDH  group  pair. 

We  presented  two  families  of  elliptic  curves  that  are  suitable  for  obtaining  short  signatures.  The 
first,  based  on  [41],  is  a  family  of  non-supersingular  curves  over  a  prime  finite  field.  The  second  uses 
supersingular  curves  over  F3£.  Both  families  of  curves  produce  n-bit  signatures  and  the  discrete  log 
problem  on  these  curves  is  reducible  to  a  discrete  log  problem  in  a  finite  field  of  size  approximately 
26n.  Using  the  first  family  of  curves,  for  1024-bit  security  we  get  signatures  of  size  approximately 
[1024/6]  =  171  bits. 

We  expect  that  the  first  family  of  curves  (the  non-supersingular  curves)  will  be  the  one  used  for 
short  signatures:  171-bit  signatures  with  1024-bit  security.  As  discussed  at  the  end  of  Section  4.4, 
the  second  family  of  curves  (the  supersingular  curve  over  F3d  should  not  be  used  for  short  signa¬ 
tures.  The  problem  is  that  discrete  log  on  these  curves  reduces  to  a  discrete  log  in  a  finite  field  of 
characteristic  3  where  Coppersmith’s  algorithm  can  be  used. 

Implementation  results  [23,  4]  indicate  that  the  signature  scheme  performs  well.  Signature 
generation  is  just  a  simple  multiplication  on  an  elliptic  curve  and  is  faster  than  RSA  signature 
generation.  Verification  requires  two  computations  of  the  bilinear  map  and  is  slower  than  RSA 
signature  verification. 

In  Section  4.5  we  outlined  an  open  problem  that  would  enable  us  to  get  even  better  security 
while  maintaining  the  same  length  signatures.  We  hope  future  work  on  constructing  elliptic  curves 
or  higher  genus  curves  will  help  in  solving  this  problem. 
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Abstract 

We  propose  a  fully  functional  identity-based  encryption  scheme  (IBE).  The  scheme  has  chosen 
ciphertext  security  in  the  random  oracle  model  assuming  a  variant  of  the  computational  Diffie- 
Hellman  problem.  Our  system  is  based  on  bilinear  maps  between  groups.  The  Weil  pairing  on 
elliptic  curves  is  an  example  of  such  a  map.  We  give  precise  definitions  for  secure  identity  based 
encryption  schemes  and  give  several  applications  for  such  systems. 


1  Introduction 

In  1984  Shamir  [41]  asked  for  a  public  key  encryption  scheme  in  which  the  public  key  can  be  an  arbitrary 
string.  In  such  a  scheme  there  are  four  algorithms:  (1)  setup  generates  global  system  parameters  and 
a  master-key,  (2)  extract  uses  the  master-key  to  generate  the  private  key  corresponding  to  an  arbitrary 
public  key  string  ID  G  {0,1}*,  (3)  encrypt  encrypts  messages  using  the  public  key  ID,  and  (4)  decrypt 
decrypts  messages  using  the  corresponding  private  key. 

Shamir’s  original  motivation  for  identity-based  encryption  was  to  simplify  certificate  management 
in  e-mail  systems.  When  Alice  sends  mail  to  Bob  at  bobOcompany .  com  she  simply  encrypts  her  message 
using  the  public  key  string  “bobScompany .  com”.  There  is  no  need  for  Alice  to  obtain  Bob’s  public  key 
certificate.  When  Bob  receives  the  encrypted  mail  he  contacts  a  third  party,  which  we  call  the  Private 
Key  Generator  (PKG).  Bob  authenticates  himself  to  the  PKG  in  the  same  way  he  would  authenticate 
himself  to  a  CA  and  obtains  his  private  key  from  the  PKG.  Bob  can  then  read  his  e-mail.  Note  that 
unlike  the  existing  secure  e-mail  infrastructure,  Alice  can  send  encrypted  mail  to  Bob  even  if  Bob 
has  not  yet  setup  his  public  key  certificate.  Also  note  that  key  escrow  is  inherent  in  identity-based 
e-mail  systems:  the  PKG  knows  Bob’s  private  key.  We  discuss  key  revocation,  as  well  as  several  new 
applications  for  IBE  schemes  in  the  next  section. 

Since  the  problem  was  posed  in  1984  there  have  been  several  proposals  for  IBE  schemes  [11,  45, 
44,  31,  25]  (see  also  [33,  p.  561]).  However,  none  of  these  are  fully  satisfactory.  Some  solutions  require 
that  users  not  collude.  Other  solutions  require  the  PKG  to  spend  a  long  time  for  each  private  key 
generation  request.  Some  solutions  require  tamper  resistant  hardware.  It  is  fair  to  say  that  until 
the  results  in  [5]  constructing  a  usable  IBE  system  was  an  open  problem.  Interestingly,  the  related 
notions  of  identity-based  signature  and  authentication  schemes,  also  introduced  by  Shamir  [41],  do 
have  satisfactory  solutions  [15,  14]. 

In  this  paper  we  propose  a  fully  functional  identity-based  encryption  scheme.  The  performance 
of  our  system  is  comparable  to  the  performance  of  ElGamal  encryption  in  IF*.  The  security  of  our 
system  is  based  on  a  natural  analogue  of  the  computational  Diffie-Hellman  assumption.  Based  on 


173 


this  assumption  we  show  that  the  new  system  has  chosen  ciphertext  security  in  the  random  oracle 
model.  Using  standard  techniques  from  threshold  cryptography  [20,  22]  the  PKG  in  our  scheme  can 
be  distributed  so  that  the  master-key  is  never  available  in  a  single  location.  Unlike  common  threshold 
systems,  we  show  that  robustness  for  our  distributed  PKG  is  free. 

Our  IBE  system  can  be  built  from  any  bilinear  map  e  :  Gi  x  Gi  — ►  G2  between  two  groups  Gi,  G2  as 
long  as  a  variant  of  the  Computational  Diffie-Hellman  problem  in  Gi  is  hard.  We  use  the  Weil  pairing 
on  elliptic  curves  as  an  example  of  such  a  map.  Until  recently  the  Weil  pairing  has  mostly  been  used  for 
attacking  elliptic  curve  systems  [32,  17].  Joux  [26]  recently  showed  that  the  Weil  pairing  can  be  used 
for  “good”  by  using  it  for  a  protocol  for  three  party  one  round  Diffie-Hellman  key  exchange.  Sakai  et 
al.  [40]  used  the  pairing  for  key  exchange  and  Verheul  [46]  used  it  to  construct  an  ElGamal  encryption 
scheme  where  each  public  key  has  two  corresponding  private  keys.  In  addition  to  our  identity-based 
encryption  scheme,  we  show  how  to  construct  an  ElGamal  encryption  scheme  with  “built-in”  key 
escrow,  i.e.,  where  one  global  escrow  key  can  decrypt  ciphertexts  encrypted  under  any  public  key. 

To  argue  about  the  security  of  our  IBE  system  we  define  chosen  ciphertext  security  for  identity- 
based  encryption.  Our  model  gives  the  adversary  more  power  than  the  standard  model  for  chosen 
ciphertext  security  [37,  2],  First,  we  allow  the  attacker  to  attack  an  arbitrary  public  key  ID  of  her 
choice.  Second,  while  mounting  a  chosen  ciphertext  attack  on  ID  we  allow  the  attacker  to  obtain  from 
the  PKG  the  private  key  for  any  public  key  of  her  choice,  other  than  the  private  key  for  ID.  This  models 
an  attacker  who  obtains  a  number  of  private  keys  corresponding  to  some  identities  of  her  choice  and 
then  tries  to  attack  some  other  public  key  ID  of  her  choice.  Even  with  the  help  of  such  queries  the 
attacker  should  have  negligible  advantage  in  defeating  the  semantic  security  of  the  system. 

The  rest  of  the  paper  is  organized  as  follows.  Several  applications  of  identity-based  encryption  are 
discussed  in  Section  1.1.  We  then  give  precise  definitions  and  security  models  in  Section  2.  We  describe 
bilinear  maps  with  certain  properties  in  Section  3.  Our  identity-based  encryption  scheme  is  presented 
in  Section  4  using  general  bilinear  maps.  Then  a  concrete  identity  based  system  from  the  Weil  pairing  is 
given  in  Section  5.  Some  extensions  and  variations  (efficiency  improvements,  distribution  of  the  master- 
key)  are  considered  in  Section  6.  Our  construction  for  ElGamal  encryption  with  a  global  escrow  key  is 
described  in  Section  7.  Section  8  gives  conclusions  and  some  open  problems.  The  Appendix  contains 
a  more  detailed  discussion  of  the  Weil  pairing. 

1.1  Applications  for  Identity-Based  Encryption 

The  original  motivation  for  identity-based  encryption  is  to  help  the  deployment  of  a  public  key  infras¬ 
tructure.  In  this  section,  we  show  several  other  unrelated  applications. 

1.1.1  Revocation  of  Public  Keys 

Public  key  certificates  contain  a  preset  expiration  date.  In  an  IBE  system  key  expiration  can  be  done  by 
having  Alice  encrypt  e-mail  sent  to  Bob  using  the  public  key:  “bob@company.com  ||  current-year”. 
In  doing  so  Bob  can  use  his  private  key  during  the  current  year  only.  Once  a  year  Bob  needs  to  obtain 
a  new  private  key  from  the  PKG.  Hence,  we  get  the  effect  of  annual  private  key  expiration.  Note 
that  unlike  the  existing  PKI,  Alice  does  not  need  to  obtain  a  new  certificate  from  Bob  every  time  Bob 
refreshes  his  private  key. 

One  could  potentially  make  this  approach  more  granular  by  encrypting  e-mail  for  Bob  using 
“bob@company.com  ||  current-date”.  This  forces  Bob  to  obtain  a  new  private  key  every  day. 
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This  might  be  possible  in  a  corporate  PKI  where  the  PKG  is  maintained  by  the  corporation.  With  this 
approach  key  revocation  is  very  simple:  when  Bob  leaves  the  company  and  his  key  needs  to  be  revoked, 
the  corporate  PKG  is  instructed  to  stop  issuing  private  keys  for  Bob’s  e-mail  address.  As  a  result.  Bob 
can  no  longer  read  his  email.  The  interesting  property  is  that  Alice  does  not  need  to  communicate  with 
any  third  party  certificate  directory  to  obtain  Bob’s  daily  public  key.  Hence,  identity  based  encryption 
is  a  very  efficient  mechanism  for  implementing  ephemeral  public  keys.  Also  note  that  this  approach 
enables  Alice  to  send  messages  into  the  future:  Bob  will  only  be  able  to  decrypt  the  e-mail  on  the  date 
specified  by  Alice  (see  [38,  12]  for  methods  of  sending  messages  into  the  future  using  a  stronger  security 
model). 


Managing  user  credentials.  A  simple  extension  to  the  discussion  above  enables  us  to  manage 
user  credentials  using  the  IBE  system.  Suppose  Alice  encrypts  mail  to  Bob  using  the  public  key: 
“bob@company.com  ||  current-year  ||  clearance=secret” .  Then  Bob  will  only  be  able  to  read 
the  email  if  on  the  specified  date  he  has  secret  clearance.  Consequently,  it  is  easy  to  grant  and  revoke 
user  credentials  using  the  PKG. 

1.1.2  Delegation  of  Decryption  Keys 

Another  application  for  IBE  systems  is  delegation  of  decryption  capabilities.  We  give  two  example 
applications.  In  both  applications  the  user  Bob  plays  the  role  of  the  PKG.  Bob  runs  the  setup  algorithm 
to  generate  his  own  IBE  system  parameters  params  and  his  own  master-key.  Here  we  view  params  as 
Bob’s  public  key.  Bob  obtains  a  certificate  from  a  CA  for  his  public  key  params.  When  Alice  wishes  to 
send  mail  to  Bob  she  first  obtains  Bob’s  public  key  params  from  Bob’s  public  key  certificate.  Note  that 
Bob  is  the  only  one  who  knows  his  master-key  and  hence  there  is  no  key-escrow  with  this  setup. 

1.  Delegation  to  a  laptop.  Suppose  Alice  encrypts  mail  to  Bob  using  the  current  date  as  the  IBE 
encryption  key  (she  uses  Bob’s  params  as  the  IBE  system  parameters).  Since  Bob  has  the  master- 
key  he  can  extract  the  private  key  corresponding  to  this  IBE  encryption  key  and  then  decrypt  the 
message.  Now,  suppose  Bob  goes  on  a  trip  for  seven  days.  Normally,  Bob  would  put  his  private  key 
on  his  laptop.  If  the  laptop  is  stolen  the  private  key  is  compromised.  When  using  the  IBE  system 
Bob  could  simply  install  on  his  laptop  the  seven  private  keys  corresponding  to  the  seven  days  of  the 
trip.  If  the  laptop  is  stolen,  only  the  private  keys  for  those  seven  days  are  compromised.  The  master- 
key  is  unharmed.  This  is  analogous  to  the  delegation  scenario  for  signature  schemes  considered  by 
Goldreich  et  al.  [23] . 

2.  Delegation  of  duties.  Suppose  Alice  encrypts  mail  to  Bob  using  the  subject  line  as  the  IBE 
encryption  key.  Bob  can  decrypt  mail  using  his  master-key.  Now,  suppose  Bob  has  several  assistants 
each  responsible  for  a  different  task  (e.g.  one  is  ‘purchasing’,  another  is  ‘human-resources’,  etc.).  Bob 
gives  one  private  key  to  each  of  his  assistants  corresponding  to  the  assistant’s  responsibility.  Each 
assistant  can  then  decrypt  messages  whose  subject  line  falls  within  its  responsibilities,  but  it  cannot 
decrypt  messages  intended  for  other  assistants.  Note  that  Alice  only  obtains  a  single  public  key  from 
Bob  (params),  and  she  uses  that  public  key  to  send  mail  with  any  subject  line  of  her  choice.  The 
mail  can  only  be  read  by  the  assistant  responsible  for  that  subject. 

More  generally,  IBE  can  simplify  security  systems  that  manage  a  large  number  of  public  keys.  Rather 
than  storing  a  big  database  of  public  keys  the  system  can  either  derive  these  public  keys  from  usernames, 
or  simply  use  the  integers  1, . . . ,  n  as  distinct  public  keys. 
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2  Definitions 


Identity-Based  Encryption.  An  identity-based  encryption  scheme  £  is  specified  by  four  random¬ 
ized  algorithms:  Setup,  Extract,  Encrypt,  Decrypt: 

Setup:  takes  a  security  parameter  k  and  returns  para  ms  (system  parameters)  and  master-key.  The 
system  parameters  include  a  description  of  a  finite  message  space  At,  and  a  description  of  a  finite 
ciphertext  space  C.  Intuitively,  the  system  parameters  will  be  publicly  known,  while  the  master-key 
will  be  known  only  to  the  “Private  Key  Generator”  (PKG). 

Extract:  takes  as  input  params,  master-key,  and  an  arbitrary  ID  £  {0, 1}*,  and  returns  a  private  key 
d.  Here  I D  is  an  arbitrary  string  that  will  be  used  as  a  public  key,  and  d  is  the  corresponding  private 
decryption  key.  The  Extract  algorithm  extracts  a  private  key  from  the  given  public  key. 

Encrypt:  takes  as  input  params,  ID,  and  M  £  At.  It  returns  a  ciphertext  C  £  C. 

Decrypt:  takes  as  input  params,  C  £  C,  and  a  private  key  d.  It  return  M  £  At. 

These  algorithms  must  satisfy  the  standard  consistency  constraint,  namely  when  d  is  the  private  key 
generated  by  algorithm  Extract  when  it  is  given  ID  as  the  public  key,  then 

VM  £  At  :  Decrypt(params,  C,  d)  =  M  where  C  =  Encrypt(params,  ID,  M) 

Chosen  ciphertext  security.  Chosen  ciphertext  security  (IND-CCA)  is  the  standard  acceptable 
notion  of  security  for  a  public  key  encryption  scheme  [37,  2,  13] .  Hence,  it  is  natural  to  require  that  an 
identity-based  encryption  scheme  also  satisfy  this  strong  notion  of  security.  However,  the  definition  of 
chosen  ciphertext  security  must  be  strengthened  a  bit.  The  reason  is  that  when  an  adversary  attacks 
a  public  key  ID  in  an  identity-based  system,  the  adversary  might  already  possess  the  private  keys  of 
users  IDi, . . . ,  ID,,  of  her  choice.  The  system  should  remain  secure  under  such  an  attack.  Hence,  the 
definition  of  chosen  ciphertext  security  must  allow  the  adversary  to  obtain  the  private  key  associated 
with  any  identity  IDj  of  her  choice  (other  than  the  public  key  ID  being  attacked).  We  refer  to  such 
queries  as  private  key  extraction  queries.  Another  difference  is  that  the  adversary  is  challenged  on  a 
public  key  ID  of  her  choice  (as  opposed  to  a  random  public  key). 

We  say  that  an  identity-based  encryption  scheme  £  is  semantically  secure  against  an  adaptive 
chosen  ciphertext  attack  (IND-ID-CCA)  if  no  polynomially  bounded  adversary  A  has  a  non-negligible 
advantage  against  the  Challenger  in  the  following  IND-ID-CCA  game: 

Setup:  The  challenger  takes  a  security  parameter  k  and  runs  the  Setup  algorithm.  It  gives 
the  adversary  the  resulting  system  parameters  params.  It  keeps  the  master-key  to  itself. 

Phase  1:  The  adversary  issues  queries  q±, ,  qrn  where  query  qi  is  one  of: 

-  Extraction  query  (IDj).  The  challenger  responds  by  running  algorithm  Extract  to  gen¬ 
erate  the  private  key  di  corresponding  to  the  public  key  (ID,;).  It  sends  di  to  the 
adversary. 

Decryption  query  (ID j,Cj).  The  challenger  responds  by  running  algorithm  Extract  to 
generate  the  private  key  dn  corresponding  to  IDj.  It  then  runs  algorithm  Decrypt  to 
decrypt  the  ciphertext  C,  using  the  private  key  dt.  It  sends  the  resulting  plaintext  to 
the  adversary. 

These  queries  may  be  asked  adaptively,  that  is,  each  query  qi  may  depend  on  the  replies 
to  qi, . . 
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Challenge:  Once  the  adversary  decides  that  Phase  1  is  over  it  outputs  two  equal  length 
plaintexts  Mq,  M±  E  AA  and  an  identity  ID  on  which  it  wishes  to  be  challenged.  The  only 
constraint  is  that  ID  did  not  appear  in  any  private  key  extraction  query  in  Phase  1. 

The  challenger  picks  a  random  bit  b  E  {0,1}  and  sets  C  =  Encrypt(params,  ID,  Mf).  It 
sends  C  as  the  challenge  to  the  adversary. 

Phase  2:  The  adversary  issues  more  queries  qm+ 1, . . . ,  qn  where  query  g*  is  one  of: 

-  Extraction  query  (IDj)  where  ID*  ^  ID.  Challenger  responds  as  in  Phase  1. 

Decryption  query  (ID i,Ci)  ^  (ID,C).  Challenger  responds  as  in  Phase  1. 

These  queries  may  be  asked  adaptively  as  in  Phase  1. 

Guess:  Finally,  the  adversary  outputs  a  guess  b'  E  {0, 1}  and  wins  the  game  if  b  =  b' . 

We  refer  to  such  an  adversary  A  as  an  IND-ID-CCA  adversary.  We  define  adversary  A’s 
advantage  in  attacking  the  scheme  £  as  the  following  function  of  the  security  parameter  k 
( k  is  given  as  input  to  the  challenger):  Advs^(k)  =  |Pr[fe  =  b']  —  ||. 

The  probability  is  over  the  random  bits  used  by  the  challenger  and  the  adversary. 

Using  the  IND-ID-CCA  game  we  can  define  chosen  ciphertext  security  for  IBE  schemes.  As  usual,  we 
say  that  a  function  g  :  M  — >  M  is  negligible  if  for  any  d  >  0  we  have  \g{k)\  <  l/kd  for  sufficiently  large  k. 

Definition  2.1.  We  say  that  the  IBE  system  £  is  semantically  secure  against  an  adaptive  chosen  ci¬ 
phertext  attack  if  for  any  polynomial  time  IND-ID-CCA  adversary  A  the  function  Adv£^(k)  is  negligible. 
As  shorthand,  we  say  that  £  is  IND-ID-CCA  secure. 

Note  that  the  standard  definition  of  chosen  ciphertext  security  (IND-CCA)  [37,  2]  is  the  same  as 
above  except  that  there  are  no  private  key  extraction  queries  and  the  adversary  is  challenged  on  a 
random  public  key  (rather  than  a  public  key  of  her  choice) .  Private  key  extraction  queries  are  related 
to  the  definition  of  chosen  ciphertext  security  in  the  multiuser  settings  [7].  After  all,  our  definition 
involves  multiple  public  keys  belonging  to  multiple  users.  In  [7]  the  authors  show  that  that  multiuser 
IND-CCA  is  reducible  to  single  user  IND-CCA  using  a  standard  hybrid  argument.  This  does  not  hold 
in  the  identity-based  settings,  IND-ID-CCA,  since  the  adversary  gets  to  choose  which  public  keys  to 
corrupt  during  the  attack.  To  emphasize  the  importance  of  private  key  extraction  queries  we  note  that 
our  IBE  system  can  be  easily  modified  (by  removing  one  of  the  hash  functions)  into  a  system  which 
has  chosen  ciphertext  security  when  private  extraction  queries  are  disallowed.  However,  the  scheme  is 
completely  insecure  when  extraction  queries  are  allowed. 


Semantically  secure  identity  based  encryption.  The  proof  of  security  for  our  IBE  system  makes 
use  of  a  weaker  notion  of  security  known  as  semantic  security  (also  known  as  semantic  security  against 
a  chosen  plaintext  attack)  [24,  2].  Semantic  security  is  similar  to  chosen  ciphertext  security  (IND-ID- 
CCA)  except  that  the  adversary  is  more  limited;  it  cannot  issue  decryption  queries  while  attacking  the 
challenge  public  key.  For  a  standard  public  key  system  (not  an  identity  based  system)  semantic  security 
is  defined  using  the  following  game:  (1)  the  adversary  is  given  a  random  public  key  generated  by  the 
challenger,  (2)  the  adversary  outputs  two  equal  length  messages  Mq  and  M\  and  receives  the  encryption 
of  Mb  from  the  challenger  where  b  is  chosen  at  random  in  {0, 1},  (3)  the  adversary  outputs  b'  and  wins 
the  game  if  b  =  b' .  The  public  key  system  is  said  to  be  semantically  secure  if  no  polynomial  time 
adversary  can  win  the  game  with  a  non-negligible  advantage.  As  shorthand  we  say  that  a  semantically 
secure  public  key  system  is  IND-CPA  secure.  Semantic  security  captures  our  intuition  that  given  a 
ciphertext  the  adversary  learns  nothing  about  the  corresponding  plaintext. 
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To  define  semantic  security  for  identity  based  systems  (denoted  IND-ID-CPA)  we  strengthen  the 
standard  definition  by  allowing  the  adversary  to  issue  chosen  private  key  extraction  queries.  Similarly, 
the  adversary  is  challenged  on  a  public  key  ID  of  her  choice.  We  define  semantic  security  for  identity 
based  encryption  schemes  using  an  IND-ID-CPA  game.  The  game  is  identical  to  the  IND-ID-CCA  game 
defined  above  except  that  the  adversary  cannot  make  any  decryption  queries.  The  adversary  can  only 
make  private  key  extraction  queries.  We  say  that  an  identity-based  encryption  scheme  £  is  semantically 
secure  (IND-ID-CPA)  if  no  polynomially  bounded  adversary  A  has  a  non-negligible  advantage  against 
the  Challenger  in  the  following  IND-ID-CPA  game: 

Setup:  The  challenger  takes  a  security  parameter  k  and  runs  the  Setup  algorithm.  It  gives 
the  adversary  the  resulting  system  parameters  params.  It  keeps  the  master-key  to  itself. 

Phase  1:  The  adversary  issues  private  key  extraction  queries  I D i , . . . ,  IDm.  The  challenger 
responds  by  running  algorithm  Extract  to  generate  the  private  key  di  corresponding  to 
the  public  key  ID,.  It  sends  di  to  the  adversary.  These  queries  may  be  asked  adaptively. 

Challenge:  Once  the  adversary  decides  that  Phase  1  is  over  it  outputs  two  equal  length 
plaintexts  Mo,  Mi  E  M.  and  a  public  key  ID  on  which  it  wishes  to  be  challenged.  The 
only  constraint  is  that  ID  did  not  appear  in  any  private  key  extraction  query  in  Phase  1. 

The  challenger  picks  a  random  bit  b  E  {0,1}  and  sets  C  =  Encrypt(params,  ID,  Mb).  It 
sends  C  as  the  challenge  to  the  adversary. 

Phase  2:  The  adversary  issues  more  extraction  queries  IDm+i, . . . ,  ID„.  The  only  constraint 
is  that  IDj  ID.  The  challenger  responds  as  in  Phase  1. 

Guess:  Finally,  the  adversary  outputs  a  guess  b'  E  {0, 1}  and  wins  the  game  if  b  =  b' . 

We  refer  to  such  an  adversary  A  as  an  IND-ID-CPA  adversary.  As  we  did  above,  the 

advantage  of  an  IND-ID-CPA  adversary  A  against  the  scheme  £  is  the  following  function  of 

the  security  parameter  k:  Adv^-^/c)  =  |Pr[6  =  b'}  —  \ |. 

The  probability  is  over  the  random  bits  used  by  the  challenger  and  the  adversary. 

Definition  2.2.  We  say  that  the  IBE  system  £  is  semantically  secure  if  for  any  polynomial  time  IND- 
ID-CPA  adversary  A  the  function  Adv£^(k)  is  negligible.  As  shorthand,  we  say  that  £  is  IND-ID-CPA 
secure. 

One  way  identity- based  encryption.  One  can  define  an  even  weaker  notion  of  security  called  one¬ 
way  encryption  (OWE)  [16].  Roughly  speaking,  a  public  key  encryption  scheme  is  a  one-way  encryption 
if  given  the  encryption  of  a  random  plaintext  the  adversary  cannot  produce  the  plaintext  in  its  entirety. 
One  way  encryption  is  a  weak  notion  of  security  since  there  is  nothing  preventing  the  adversary  from, 
say,  learning  half  the  bits  of  the  plaintext.  Hence,  one-way  encryption  schemes  do  not  generally  provide 
secure  encryption.  In  the  random  oracle  model  one-way  encryption  schemes  can  be  used  for  encrypting 
session-keys  (the  session-key  is  taken  to  be  the  hash  of  the  plaintext).  We  note  that  one  can  extend 
the  notion  of  one-way  encryption  to  identity  based  systems  by  adding  private  key  extraction  queries  to 
the  definition.  We  do  not  give  the  full  definition  here  since  in  this  paper  we  use  semantic  security  as 
the  weakest  notion  of  security.  See  [5]  for  the  full  definition  of  identity  based  one-way  encryption,  and 
its  use  as  part  of  an  alternative  proof  strategy  for  our  main  result. 

Random  oracle  model.  To  analyze  the  security  of  certain  natural  cryptographic  constructions  Bel- 
lare  and  Rogaway  introduced  an  idealized  security  model  called  the  random  oracle  model  [3].  Roughly 
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speaking,  a  random  oracle  is  a  function  H  :  X  — ►  Y  chosen  uniformly  at  random  from  the  set  of  all 
functions  {h  :  X  — ►  Y}  (we  assume  Y  is  a  finite  set).  An  algorithm  can  query  the  random  oracle  at 
any  point  x  €  X  and  receive  the  value  H(x )  in  response.  Random  oracles  are  used  to  model  crypto¬ 
graphic  hash  functions  such  as  SHA-1.  Note  that  security  in  the  random  oracle  model  does  not  imply 
security  in  the  real  world.  Nevertheless,  the  random  oracle  model  is  a  useful  tool  for  validating  natural 
cryptographic  constructions.  Security  proofs  in  this  model  prove  security  against  attackers  that  are 
confined  to  the  random  oracle  world. 

Notation.  From  here  on  we  use  Zg  to  denote  the  group  {0,  —  1}  under  addition  modulo  q.  For 

a  group  G  of  prime  order  we  use  G*  to  denote  the  set  G*  =  G  \  {O}  where  O  is  the  identity  element 
in  the  group  G.  We  use  Z+  to  denote  the  set  of  positive  integers. 


3  Bilinear  maps  and  the  Bilinear  Diffie-Hellman  Assumption 

Let  Gi  and  G2  be  two  groups  of  order  q  for  some  large  prime  q.  Our  IBE  system  makes  use  of  a  bilinear 
map  e  :  Gj  x  Gi  ->  G2  between  these  two  groups.  The  map  must  satisfy  the  following  properties: 

1.  Bilinear:  We  say  that  a  map  e  :  Gi  x  Gi  — >  G2  is  bilinear  if  e(aP,  bQ)  =  e(P,  Q)ab  for  all  P,Q  G  Gi 
and  all  a,  b  G  Z. 

2.  Non-degenerate:  The  map  does  not  send  all  pairs  in  Gi  x  Gi  to  the  identity  in  G2.  Observe  that 
since  Gi,G2  are  groups  of  prime  order  this  implies  that  if  P  is  a  generator  of  Gi  then  e(P,P)  is  a 
generator  of  G2. 

3.  Computable:  There  is  an  efficient  algorithm  to  compute  e(P,  Q )  for  any  P.Q  £  G 1 . 

A  bilinear  map  satisfying  the  three  properties  above  is  said  to  be  an  admissible  bilinear  map.  In 
Section  5  we  give  a  concrete  example  of  groups  Gi,G2  and  an  admissible  bilinear  map  between  them. 
The  group  Gi  is  a  subgroup  of  the  additive  group  of  points  of  an  elliptic  curve  E/Fp.  The  group  G2  is  a 
subgroup  of  the  multiplicative  group  of  a  finite  field  F*2.  Therefore,  throughout  the  paper  we  view  Gi 
as  an  additive  group  and  G2  as  a  multiplicative  group.  As  we  will  see  in  Section  5.1,  the  Weil  pairing 
can  be  used  to  construct  an  admissible  bilinear  map  between  these  two  groups. 

The  existence  of  the  bilinear  map  e  :  Gi  x  Gi  — ►  G2  as  above  has  two  direct  implications  to  these 
groups. 

The  MOV  reduction:  Menezes,  Okamoto,  and  Vanstone  [32]  show  that  the  discrete  log  problem  in 
Gi  is  no  harder  than  the  discrete  log  problem  in  G2.  To  see  this,  let  P,Q  6  Gj  be  an  instance 
of  the  discrete  log  problem  in  Gi  where  both  P,  Q  have  order  q.  We  wish  to  find  an  a  6  such 
that  Q  =  aP.  Let  g  =  e(P,  P )  and  h  =  e(Q,  P).  Then,  by  bilinearity  of  e  we  know  that  h  =  ga. 
By  non-degeneracy  of  e  both  g,  h  have  order  q  in  G2.  Hence,  we  reduced  the  discrete  log  problem 
in  Gi  to  a  discrete  log  problem  in  G2.  It  follows  that  for  discrete  log  to  be  hard  in  Gi  we  must 
choose  our  security  parameter  so  that  discrete  log  is  hard  in  G2  (see  Section  5). 

Decision  Diffie-Hellman  is  Easy:  The  Decision  Diffie-Hellman  problem  (DDH)  [4]  in  Gi  is  to  dis¬ 
tinguish  between  the  distributions  (. P ,  aP,  bP,  abP)  and  (P,  aP ,  bP ,  cP)  where  a,  b,  c  are  random 
in  Z*  and  P  is  random  in  G]\  Joux  and  Nguyen  [28]  point  out  that  DDH  in  Gi  is  easy.  To  see 
this,  observe  that  given  P,  aP,  bP ,  cP  €  G][  we  have 

c  =  ab  mod  q  <*=>•  e(P,  cP )  =  e(aP ,  bP). 
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The  Computational  Diffie-Hellman  problem  (CDH)  in  Gi  can  still  be  hard  (CDH  in  G\  is  to  find 
abP  given  random  ( P ,  aP ,  bP)).  Joux  and  Nguyen  [28]  give  examples  of  mappings  e  :  Gi  x  Gi  — > 
G2  where  CDH  in  Gi  is  believed  to  be  hard  even  though  DDH  in  Gi  is  easy. 

3.1  The  Bilinear  Diffie-Hellman  Assumption  (BDH) 

Since  the  Decision  Diffie-Hellman  problem  (DDH)  in  Gi  is  easy  we  cannot  use  DDH  to  build  cryp¬ 
tosystems  in  the  group  Gi.  Instead,  the  security  of  our  IBE  system  is  based  on  a  variant  of  the 
Computational  Diffie-Hellman  assumption  called  the  Bilinear  Diffie-Hellman  Assumption  (BDH). 


Bilinear  Diffie-Hellman  Problem.  Let  Gi,G2  be  two  groups  of  prime  order  q.  Let  e  :  Gi  x  Gi  — » 
G2  be  an  admissible  bilinear  map  and  let  P  be  a  generator  of  Gi.  The  BDH  problem  in  (Gi,  G2,  e)  is 
as  follows:  Given  (P,  aP ,  bP,  cP)  for  some  a,  b,  c  e  Z*  compute  W  =  e(P,  P)abc  g  G2.  An  algorithm  A 
has  advantage  e  in  solving  BDH  in  (Gi,  G2,  e)  if 


Pr 


A(P,  aP ,  bP,  cP )  =  e(P,  P)abc 


>  e 


where  the  probability  is  over  the  random  choice  of  a,  b,  c  in  Z*,  the  random  choice  of  P  £  G[,  and  the 
random  bits  of  A. 


BDH  Parameter  Generator.  We  say  that  a  randomized  algorithm  Q  is  a  BDH  parameter  generator 
if  (1)  Q  takes  a  security  parameter  k  G  Z+,  (2)  Q  runs  in  polynomial  time  in  k,  and  (3)  Q  outputs  a 
prime  number  q.  the  description  of  two  groups  Gi,G2  of  order  q,  and  the  description  of  an  admissible 
bilinear  map  e  :  Gi  x  Gi  — ►  G2.  We  denote  the  output  of  Q  by  Q(lk)  =  (<7,  Gi,  G2,  e).  The  security 
parameter  k  is  used  to  determine  the  size  of  q ;  for  example,  one  could  take  q  to  be  a  random  fc-bit 
prime.  For  i  =  1,2  we  assume  that  the  description  of  the  group  G*  contains  polynomial  time  (in  k) 
algorithms  for  computing  the  group  action  in  Gj  and  contains  a  generator  of  G*.  The  generator  of  Gj 
enables  us  to  generate  uniformly  random  elements  in  Gj.  Similarly,  we  assume  that  the  description  of 
e  contains  a  polynomial  time  algorithm  for  computing  e.  We  give  an  example  of  a  BDH  parameter 
generator  in  Section  5.1. 


BDH  Assumption.  Let  Q  be  a  BDH  parameter  generator.  We  say  that  an  algorithm  A  has  advan¬ 
tage  e(k)  in  solving  the  BDH  problem  for  Q  if  for  sufficiently  large  k: 


Advg^(fc)  =  Pr 


A(q,  Gi,  G2,  e,  P,  aP,  bP,  cP)  =  e(P,  P)abc 


(q,  Gi,  G2,  e)  <—  G{lk), 
P  <-  G*,  a,  6,  c  <—  Z* 


>  e(k) 


We  say  that  Q  satisfies  the  BDH  assumption  if  for  any  randomized  polynomial  time  (in  k)  algorithm 
A  we  have  that  Advg^(k)  is  a  negligible  function.  When  Q  satisfies  the  BDH  assumption  we  say  that 
BDH  is  hard  in  groups  generated  by  Q. 

In  Section  5.1  we  give  some  examples  of  BDH  parameter  generators  that  are  believed  to  satisfy 
the  BDH  assumption.  We  note  that  Joux  [26]  (implicitly)  used  the  BDH  assumption  to  construct  a 
one-round  three  party  Diffie-Hellman  protocol.  The  BDH  assumption  is  also  needed  for  constructions 
in  [46,  40]. 
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Hardness  of  BDH.  It  is  interesting  to  study  the  relationship  of  the  BDH  problem  to  other  hard 
problems  used  in  cryptography.  Currently,  all  we  can  say  is  that  the  BDH  problem  in  (Gi,G2,e)  is 
no  harder  than  the  CDH  problem  in  Gi  or  G2.  In  other  words,  an  algorithm  for  CDH  in  Gi  or  G2  is 
sufficient  for  solving  BDH  in  (Gi,G2,e).  The  converse  is  currently  an  open  problem:  is  an  algorithm 
for  BDH  sufficient  for  solving  CDH  in  Gi  or  in  G2?  We  refer  to  a  survey  by  Joux  [27]  for  a  more 
detailed  analysis  of  the  relationship  between  BDH  and  other  standard  problems. 

We  note  that  in  all  our  examples  (in  Section  5.1)  the  isomorphisms  from  Gi  to  G2  induced  by  the 
bilinear  map  are  believed  to  be  one-way  functions.  More  specifically,  for  a  point  Q  £  G{  define  the 
isomorphism  fg  :  Gi  — >  G2  by  f q(P )  =  e(P,Q).  If  any  one  of  these  isomorphisms  turns  out  to  be 
invertible  then  BDH  is  easy  in  (Gi,  G2,  e).  Fortunately,  an  efficient  algorithm  for  inverting  fg  for  some 
fixed  Q  would  imply  an  efficient  algorithm  for  deciding  DDH  in  the  group  G2.  In  all  our  examples 
DDH  is  believed  to  be  hard  in  the  group  G2.  Hence,  all  the  isomorphisms  fg  :  Gi  — ►  G2  induced  by 
the  bilinear  map  are  believed  to  be  one-way  functions. 


4  Our  Identity-Based  Encryption  Scheme 

We  describe  our  scheme  in  stages.  First  we  give  a  basic  identity-based  encryption  scheme  which  is  not 
secure  against  an  adaptive  chosen  ciphertext  attack.  The  only  reason  for  describing  the  basic  scheme 
is  to  make  the  presentation  easier  to  follow.  Our  full  scheme,  described  in  Section  4.2,  extends  the 
basic  scheme  to  get  security  against  an  adaptive  chosen  ciphertext  attack  (IND-ID-CCA)  in  the  random 
oracle  model.  In  Section  4.3  we  relax  some  of  the  requirements  on  the  hash  functions. 

The  presentation  in  this  section  uses  an  arbitrary  BDH  parameter  generator  Q  satisfying  the  BDH 
assumption.  In  Section  5  we  describe  a  concrete  IBE  system  using  the  Weil  pairing. 

4.1  Basicldent 

To  explain  the  basic  ideas  underlying  our  IBE  system  we  describe  the  following  simple  scheme,  called 
Basicldent.  We  present  the  scheme  by  describing  the  four  algorithms:  Setup,  Extract,  Encrypt,  Decrypt. 
We  let  k  be  the  security  parameter  given  to  the  setup  algorithm.  We  let  Q  be  some  BDH  parameter 
generator. 

Setup:  Given  a  security  parameter  k  £  Z+,  the  algorithm  works  as  follows: 

Step  1:  Run  Q  on  input  k  to  generate  a  prime  q,  two  groups  Gi,G2  of  order  q,  and  an  admissible 
bilinear  map  e  :  Gj  x  Gi  ->  G2.  Choose  a  random  generator  P  £  Gi. 

Step  2:  Pick  a  random  s  £  Z*  and  set  Ppub  =  sP. 

Step  3:  Choose  a  cryptographic  hash  function  H\  :  {0,1}*  — »  G{.  Choose  a  cryptographic  hash 
function  H2  :  G2  — >  {0,  l}n  for  some  n.  The  security  analysis  will  view  H\,  H-2  as  random  oracles. 
The  message  space  is  M  =  {0,  l}n.  The  ciphertext  space  is  C  =  G{  x  {0,  l}n.  The  system  parameters 
are  params  =  (q,  Gi,  G2,  e,  n,  P,  Ppub,  The  master-key  is  s  £  Z*. 

Extract:  For  a  given  string  ID  £  {0,1}*  the  algorithm  does:  (1)  computes  Qm  =  Hi(ID)  £  G{,  and 
(2)  sets  the  private  key  dm  to  be  dID  =  sQ ,D  where  s  is  the  master  key. 

Encrypt:  To  encrypt  M  £  A4  under  the  public  key  ID  do  the  following:  (1)  compute  Q ID  =  Hi(ID)  £ 
G{,  (2)  choose  a  random  r  £  Z*,  and  (3)  set  the  ciphertext  to  be 

C  =  (rP,  M  ©  H2{glD)}  where  g,D  =  e(Qm,  Ppub)  £  G2 
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Decrypt:  Let  C  =  ( U ,  V)  £  C  be  a  ciphertext  encrypted  using  the  public  key  ID.  To  decrypt  C  using 
the  private  key  dlD  £  Gf  compute: 

V  ®  H2(e(dlD,U))  =  M 

This  completes  the  description  of  Basicldent.  We  first  verify  consistency.  When  everything  is  computed 
as  above  we  have: 

1.  During  encryption  M  is  bitwise  exclusive-ored  with  the  hash  of:  gfD. 

2.  During  decryption  V  is  bitwise  exclusive-ored  with  the  hash  of:  e(dID,  U ). 

These  masks  used  during  encryption  and  decryption  are  the  same  since: 

e(c?iD,  U)  =  e(sQ id,  rP)  =  e(Qm,  P)sr  =  e(Q,D,  PpubY  =  9m 

Thus,  applying  decryption  after  encryption  produces  the  original  message  M  as  required.  Performance 
considerations  of  Basicldent  are  discussed  in  Section  5.  Note  that  the  value  of  gm  in  Algorithm  Encrypt 
is  independent  of  the  message  to  be  encrypted.  Hence  there  is  no  need  to  recompute  gm  on  subsequent 
encryptions  to  the  same  public  key  ID. 


Security.  Next,  we  study  the  security  of  this  basic  scheme.  The  following  theorem  shows  that 
Basicldent  is  a  semantically  secure  identity  based  encryption  scheme  (IND-ID-CPA)  assuming  BDH  is 
hard  in  groups  generated  by  Q. 


Theorem  4.1.  Suppose  the  hash  functions  H\,H2  are  random  oracles.  Then  Basicldent  is  a  semanti¬ 
cally  secure  identity  based  encryption  scheme  (IND-ID-CPAj  assuming  BDH  is  hard  in  groups  generated 
by  Q .  Concretely,  suppose  there  is  an  IND-ID-CPA  adversary  A  that  has  advantage  e(k)  against  the 
scheme  Basicldent.  Suppose  A  makes  at  most  qE  >  0  private  key  extraction  queries  and  qH2  >  0  hash 
queries  to  H2.  Then  there  is  an  algorithm  B  that  solves  BDH  in  groups  generated  by  Q  with  advantage 
at  least: 


Advg^ik)  > 


2  e(k) 

e(l  +  qE)  •  qH2 


Here  e  «  2.71  is  the  base  of  the  natural  logarithm.  The  running  time  of  B  is  0(time(A)) . 

To  prove  the  theorem  we  first  define  a  related  Public  Key  Encryption  scheme  (not  an  identity  based 
scheme),  called  BasicPub.  BasicPub  is  described  by  three  algorithms:  keygen,  encrypt,  decrypt. 

keygen:  Given  a  security  parameter  k  £  Z+,  the  algorithm  works  as  follows: 

Step  1:  Run  Q  on  input  k  to  generate  two  prime  order  groups  Gi,  G2  and  a  bilinear  map  e  :  GjxGi  -> 
G2.  Let  q  be  the  order  of  Gi,G2-  Choose  a  random  generator  P  £  Gi. 

Step  2:  Pick  a  random  s  £  Z*  and  set  Ppub  =  sP.  Pick  a  random  Qm  £  Gf . 

Step  3:  Choose  a  cryptographic  hash  function  H2  :  G2  — ►  {0,  l}n  for  some  n. 

Step  4:  The  public  key  is  (q,  Gi,  G2,  e,  n,  P ,  Ppub,  Qm ,  H2).  The  private  key  is  dm  =  sQm  £  Gf . 
encrypt:  To  encrypt  M  £  {0,  l}n  choose  a  random  r  £  Z*  and  set  the  ciphertext  to  be: 


C  =  { rP ,  M  ©  H2(gr))  where  g  =  e(Q,0,  Ppub )  £  G2 


decrypt:  Let  C  =  (U,  V)  be  a  ciphertext  created  using  the  public  key  ( q ,  Gi,  G2,  e,  n,  P,  Ppub,  Qm ,  H2). 
To  decrypt  C  using  the  private  key  dm  £  Gf  compute: 


V  ©  H2(e(dm,  U))  =  M 
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This  completes  the  description  of  BasicPub.  We  now  prove  Theorem  4.1  in  two  steps.  We  first  show 
that  an  IND-ID-CPA  attack  on  Basicldent  can  be  converted  to  a  IND-CPA  attack  on  BasicPub.  This 
step  shows  that  private  key  extraction  queries  do  not  help  the  adversary.  We  then  show  that  BasicPub 
is  IND-CPA  secure  if  the  BDH  assumption  holds. 

Lemma  4.2.  Let  Hi  be  a  random  oracle  from  {0, 1}*  to  G*.  Let  A  be  an  IND-ID-CPA  adversary  that 
has  advantage  e(k)  against  Basicldent.  Suppose  A  makes  at  most  qE  >  0  private  key  extraction  queries. 
Then  there  is  a  IND-CPA  adversary  B  that  has  advantage  at  least  e(k)/e(  1  +  qE)  against  BasicPub.  Its 
running  time  is  0(time(A)). 

Proof.  We  show  how  to  construct  an  IND-CPA  adversary  B  that  uses  A  to  gain  advantage  e/e(l  +  qE) 
against  BasicPub.  The  game  between  the  challenger  and  the  adversary  B  starts  with  the  challenger 
first  generating  a  random  public  key  by  running  algorithm  keygen  of  BasicPub.  The  result  is  a  public 
key  Kpub  =  (q,  Gi,  G2,  e,  n,  P,  Ppub,  Q\d,  ip)  and  a  private  key  dID  =  sQm.  As  usual,  q  is  the  order  of 
Gi,G2.  The  challenger  gives  Kpub  to  algorithm  B.  Algorithm  B  is  supposed  to  output  two  messages 
Mo  and  M\  and  expects  to  receive  back  the  BasicPub  encryption  of  Mb  under  Kpub  where  b  £  {0, 1}. 
Then  algorithm  B  outputs  its  guess  b'  £  {0, 1}  for  b. 

Algorithm  B  works  by  interacting  with  A  in  an  IND-ID-CPA  game  as  follows  (B  simulates  the  challenger 
for  A): 

Setup:  Algorithm  B  gives  A  the  Basicldent  system  parameters  (q,  Gi,  G2,  e,  n,  P,  Ppub,  Hi,  M2).  Here 
<7, Gi,G2,  e,  n,  P,  Ppub,  ip  are  taken  from  Kpub,  and  ip  is  a  random  oracle  controlled  by  B  as 
described  below. 

ip-queries:  At  any  time  algorithm  A  can  query  the  random  oracle  H\.  To  respond  to  these  queries 
algorithm  B  maintains  a  list  of  tuples  ( I D ^ ,  Qj,  bj,  Cj)  as  explained  below.  We  refer  to  this  list  as  the 
H[lst.  The  list  is  initially  empty.  When  A  queries  the  oracle  H\  at  a  point  ID,  algorithm  B  responds 
as  follows: 

1.  If  the  query  I D/  already  appears  on  the  Hlfst  in  a  tuple  (ID,;,  Qi,  bi,Ci )  then  Algorithm  B  responds 
with  ip(IDj)  =  Qi  £  GJ. 

2.  Otherwise,  B  generates  a  random  coin  £  {0, 1}  so  that  Pr[com  =  0]  =  5  for  some  5  that  will  be 
determined  later. 

3.  Algorithm  B  picks  a  random  b  £  Z*. 

If  coin  =  0  compute  Qi  =  bP  £  Gf.  If  com  =  1  compute  Qi  =  bQm  £  Gf. 

4.  Algorithm  B  adds  the  tuple  (ID*,  Qi,  b,  coin)  to  the  H\lst  and  responds  to  A  with  ip(IDj)  =  Qi. 
Note  that  either  way  Qi  is  uniform  in  Gf  and  is  independent  of  A’s  current  view  as  required. 

Phase  1:  Let  IDj  be  a  private  key  extraction  query  issued  by  algorithm  A.  Algorithm  B  responds  to 
this  query  as  follows: 

1.  Run  the  above  algorithm  for  responding  to  ip -queries  to  obtain  a  Qi  £  Gf  such  that  ip(ID,)  =  Qi. 
Let  (ID i,  Qi,bi,  coini)  be  the  corresponding  tuple  on  the  H [lst.  If  coin*  =  1  then  B  reports  failure 
and  terminates.  The  attack  on  BasicPub  failed. 

2.  We  know  coini  =  0  and  hence  Qi  =  pP.  Define  di  =  biPpub  £  Gf.  Observe  that  di  =  sQi  and 
therefore  di  is  the  private  key  associated  to  the  public  key  IDj.  Give  dt  to  algorithm  A. 

Challenge:  Once  algorithm  A  decides  that  Phase  1  is  over  it  outputs  a  public  key  IDC^  and  two 
messages  Mo,  Mi  on  which  it  wishes  to  be  challenged.  Algorithm  B  responds  as  follows: 

1.  Algorithm  B  gives  its  challenger  the  messages  Mo,  Mi.  The  challenger  responds  with  a  BasicPub 
ciphertext  C  =  (U,  V)  such  that  C  is  the  encryption  of  Mc  for  a  random  c  £  {0, 1}. 

2.  Next,  B  runs  the  algorithm  for  responding  to  ip-queries  to  obtain  aQ  £  Gj  such  that  ip(IDc/j)  = 
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Q.  Let  (I Dc^,  Q,  6,  coin )  be  the  corresponding  tuple  on  the  Hlfst.  If  coin  =  0  then  B  reports  failure 
and  terminates.  The  attack  on  BasicPub  failed. 

3.  We  know  coin  =  1  and  therefore  Q  =  bQm.  Recall  that  when  C  =  (U,V)  we  have  U  6  G)\ 
Set  C'  =  ( b~1U ,  V),  where  6_1  is  the  inverse  of  b  mod  q.  Algorithm  B  responds  to  A  with  the 
challenge  ciphertext  C' .  Note  that  C'  is  a  proper  Basicldent  encryption  of  Mc  under  the  public  key 
IDcft  as  required.  To  see  this  first  observe  that,  since  H i(IDcft)  =  Q,  the  private  key  corresponding 
to  IDcft  is  dch  =  sQ.  Second,  observe  that 

e(b~1U,  dch)  =  e{b~1U,  sQ)  =  e{U,sb~lQ)  =  e{U,sQtD)  =  e{U,dID). 

Hence,  the  Basicldent  decryption  of  C  using  dch  is  the  same  as  the  BasicPub  decryption  of  C  using 

d\D- 

Phase  2:  Algorithm  B  responds  to  private  key  extraction  queries  as  in  Phase  1. 

Guess:  Eventually  algorithm  A  outputs  a  guess  c'  for  c.  Algorithm  B  outputs  d  as  its  guess  for  c. 

Claim:  If  algorithm  B  does  not  abort  during  the  simulation  then  algorithm  A’s  view  is  identical  to 

its  view  in  the  real  attack.  Furthermore,  if  B  does  not  abort  then  |  Pr[c  =  c'}  —  \  \  >  e.  The  probability 
is  over  the  random  bits  used  by  A,  B  and  the  challenger. 

Proof  of  claim.  The  responses  to  P) -queries  are  as  in  the  real  attack  since  each  response  is  uniformly 
and  independently  distributed  in  Gf .  All  responses  to  private  key  extraction  queries  are  valid.  Finally, 
the  challenge  ciphertext  C'  given  to  A  is  the  Basicldent  encryption  of  Mc  for  some  random  c  E  {0, 1}. 
Therefore,  by  definition  of  algorithm  A  we  have  that  |  Pr[c  =  c'\  —  ||  >  e.  □ 

To  complete  the  proof  of  Lemma  4.2  it  remains  to  calculate  the  probability  that  algorithm  B  aborts 
during  the  simulation.  Suppose  A  makes  a  total  of  qE  private  key  extraction  queries.  Then  the  prob¬ 
ability  that  B  does  not  abort  in  phases  1  or  2  is  5qE .  The  probability  that  it  does  not  abort  during 
the  challenge  step  is  1  —  5.  Therefore,  the  probability  that  B  does  not  abort  during  the  simulation 
is  5qB(  1  —  5).  This  value  is  maximized  at  5opt  =  1  —  1  /(qE  +  1).  Using  5opt,  the  probability  that  B 
does  not  abort  is  at  least  l/e(l +qE).  This  shows  that  £>’ s  advantage  is  at  least  e/e(l +qE)  as  required.  □ 

The  analysis  used  in  the  proof  of  Lemma  4.2  uses  a  similar  technique  to  Coron’s  analysis  of  the 
Full  Domain  Hash  signature  scheme  [9].  Next,  we  show  that  BasicPub  is  a  semantically  secure  public 
key  system  if  the  BDH  assumption  holds. 

Lemma  4.3.  Let  H2  be  a  random  oracle  from  G2  to  {0,  l}n.  Let  A  be  an  IND-CPA  adversary  that  has 
advantage  e(k)  against  BasicPub.  Suppose  A  makes  a  total  of  qH2  >  0  queries  to  H-2-  Then  there  is  an 
algorithm  B  that  solves  the  BDH  problem  for  Q  with  advantage  at  least  2 e(k)/qH2  and  a  running  time 
0{time(A)). 

Proof.  Algorithm  B  is  given  as  input  the  BDH  parameters  (q,  Gi,G2,e)  produced  by  Q  and  a 
random  instance  (P,  aP,bP,  cP)  =  (P,  Pi,  P2,  P3)  of  the  BDH  problem  for  these  parameters,  i.e.  P  is 
random  in  G^  and  a,  6,  c  are  random  in  Z*  where  q  is  the  order  of  Gi,  G2.  Let  D  =  e(P,  P)abc  £  G2  be 
the  solution  to  this  BDH  problem.  Algorithm  B  finds  D  by  interacting  with  A  as  follows: 

Setup:  Algorithm  B  creates  the  BasicPub  public  key  Kpub  =  ( q ,  Gi,  G2,  e,  n,  P ,  Ppub,  Q id,  H2)  by  setting 
Ppub  =  Pi  and  QID  =  P2.  Here  H2  is  a  random  oracle  controlled  by  B  as  described  below.  Algorithm 
B  gives  A  the  BasicPub  public  key  Kpub.  Observe  that  the  (unknown)  private  key  associated  to  Kpub 
is  ri,D  =  a<2iD  =  abP. 
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./^-queries:  At  any  time  algorithm  A  may  issue  queries  to  the  random  oracle  H2.  To  respond  to 
these  queries  B  maintains  a  list  of  tuples  called  the  H1)31.  Each  entry  in  the  list  is  a  tuple  of  the  form 
(Xj,Hj).  Initially  the  list  is  empty.  To  respond  to  query  Xj  algorithm  B  does  the  following: 

1.  If  the  query  Xi  already  appears  on  the  Hi)31  in  a  tuple  (Xi,Hi)  then  respond  with  H2(Xi)  =  H{. 

2.  Otherwise,  B  just  picks  a  random  string  Ht  £  {0,  l}n  and  adds  the  tuple  (A*,  Hi)  to  the  Hi)31 .  It 
responds  to  A  with  H-2(Xi)  =  Hi. 

Challenge:  Algorithm  A  outputs  two  messages  Mq,Mi  on  which  it  wishes  to  be  challenged.  Al¬ 
gorithm  B  picks  a  random  string  R  £  {0,l}n  and  defines  C  to  be  the  ciphertext  C  =  (P3,R). 
Algorithm  B  gives  C  as  the  challenge  to  A.  Observe  that,  by  definition,  the  decryption  of  C  is 
R®H2(e(P3,dlD))  =  RQH2(D). 

Guess:  Algorithm  A  outputs  its  guess  d  £  {0, 1}.  At  this  point  B  picks  a  random  tuple  (Xj,  Hj)  from 
the  Hl2St  and  outputs  Xj  as  the  solution  to  the  given  instance  of  BDH. 

Algorithm  B  is  simulating  a  real  attack  environment  for  algorithm  A  (it  simulates  the  challenger  and 
the  oracle  for  H2).  We  show  that  algorithm  B  outputs  the  correct  answer  D  with  probability  at  least 
2e/qHo  as  required.  The  proof  is  based  on  comparing  A’s  behavior  in  the  simulation  to  its  behavior  in 
a  real  IND-CPA  attack  game  (against  a  real  challenger  and  a  real  random  oracle  for  H 2). 

Let  H  be  the  event  that  algorithm  A  issues  a  query  for  H2(D)  at  some  point  during  the  simulation 
above  (this  implies  that  at  the  end  of  the  simulation  D  appears  in  some  tuple  on  the  Hi)'31 ) .  We  show 
that  Pr[7-f]  >  2e.  This  will  prove  that  algorithm  B  outputs  D  with  probability  at  least  2 e/qH2.  We 
also  study  event  Ti  in  the  real  attack  game,  namely  the  event  that  A  issues  a  query  for  H2(D)  when 
communicating  with  a  real  challenger  and  a  real  random  oracle  for  H 2. 

Claim  1:  Pr[7i]  in  the  simulation  above  is  equal  to  Pr[7i]  in  the  real  attack. 

Proof  of  claim.  Let  be  the  event  that  A  makes  a  query  for  H2(D)  in  one  of  its  first  ^  queries  to 
the  H2  oracle.  We  prove  by  induction  on  l  that  Pr [He\  in  the  real  attack  is  equal  to  Pr [He]  in  the 
simulation  for  all  £  >  0.  Clearly  Pr[Lto]  =  0  in  both  the  simulation  and  in  the  real  attack.  Now  suppose 
that  for  some  i  >  0  we  have  that  Pr[?f£_i]  in  the  simulation  is  equal  to  Pr[L^_i]  in  the  real  attack. 
We  show  that  the  same  holds  for  H?.  We  know  that: 

Pr  [Ht]  =  Pr  [Hi  I  He- 1]  Pr[W*_i]  +  Pr  [He  \  -Ht-i]  Pr[-VH*_i]  (1) 

=  Pr  [He-i]  +  Pr  [He  \  -He- 1]  Prh^-i] 

We  argue  that  Pr  [He  \  ~He- 1]  in  the  simulation  is  equal  to  Pr  [He  \  ->Hf_  1]  in  the  real  attack.  To  see 
this  observe  that  as  long  as  A  does  not  issue  a  query  for  H2(D )  its  view  during  the  simulation  is 
identical  to  its  view  in  the  real  attack  (against  a  real  challenger  and  a  real  random  oracle  for  H2). 
Indeed,  the  public-key  and  the  challenge  are  distributed  as  in  the  real  attack.  Similarly,  all  responses 
to  L/2-queries  are  uniform  and  independent  in  {0,  l}n.  Therefore,  Pr  [Hi  \  in  the  simulation  is 

equal  to  Pr[?^  |  ~He--\\  in  the  real  attack.  It  follows  by  (1)  and  the  inductive  hypothesis  that  Pr[7^] 
in  the  real  attack  is  equal  to  Pr[7~A]  in  the  simulation.  By  induction  on  t  we  obtain  that  Pr[7d]  in  the 
real  attack  is  equal  to  Pr[7i]  in  the  simulation.  □ 

Claim  2:  In  the  real  attack  we  have  Pr[7d]  >  2e. 

Proof  of  claim.  In  the  real  attack,  if  A  never  issues  a  query  for  H2(D)  then  the  decryption  of  C 
is  independent  of  A's  view  (since  H2(D)  is  independent  of  A’s  view).  Therefore,  in  the  real  attack 
Pr[c  =  d  |  ~H\  =  1/2.  By  definition  of  A,  we  know  that  in  the  real  attack  |  Pr[c  =  d]  —  1/2|  >  e. 
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We  show  that  these  two  facts  imply  that  Pr[74]  >  2e.  To  do  so  we  first  derive  simple  upper  and  lower 
bounds  on  Pr[c  =  c'\. 

Pr[c  =  c]  =  Pr[c  =  d\^H\  Pr  [-.«]  +  Pr[c  =  c  \H]  Pr  [H]  < 

<  Pr [c  =  c'hH]  Pr [-.ft]  +  Pr [H]  =  ^  Pr [-.ft]  +  Pr [H]  =  ^  ^  Pr [H\ 

Pr[c  =  d]  >  Pr[c  =  c'j-iTf]  Pr[— i7Y]  =  ^  ^  Pr[7Y] 

It  follows  that  e  <  |  Pr[c  =  d]  —  1/2|  <  \  Pr[74],  Therefore,  in  the  real  attack  Pr[7i]  >  2e.  □ 

To  complete  the  proof  of  Lemma  4.3  observe  that  by  Claims  1  and  2  we  know  that  Pr[74]  >  2e  in 
the  simulation  above.  Hence,  at  the  end  of  the  simulation,  D  appears  in  some  tuple  on  the  with 
probability  at  least  2e.  It  follows  that  B  produces  the  correct  answer  with  probability  at  least  2 e/qH2 
as  required.  □ 

We  note  that  one  can  slightly  vary  the  reduction  in  the  proof  above  to  obtain  different  bounds. 
For  example,  in  the  ‘Guess’  step  above  one  can  avoid  having  to  pick  a  random  element  from  the 
by  using  the  random  self  reduction  of  the  BDH  problem.  This  requires  running  algorithm  A  multiple 
times  (as  in  Theorem  7  of  [42]).  The  success  probability  for  solving  the  given  BDH  problem  increases 
at  the  cost  of  also  increasing  the  running  time. 

Proof  of  Theorem  4.1.  The  theorem  follows  directly  from  Lemma  4.2  and  Lemma  4.3.  Composing 
both  reductions  shows  that  an  IND-ID-CPA  adversary  on  Basicldent  with  advantage  e(k )  gives  a  BDH 
algorithm  for  Q  with  advantage  at  least  2e(A:)/e(l  +  qE)QH2 ,  as  required.  □ 


4.2  Identity-Based  Encryption  with  Chosen  Ciphertext  Security 

We  use  a  technique  due  to  Fujisaki-Okamoto  [16]  to  convert  the  Basicldent  scheme  of  the  previous 
section  into  a  chosen  ciphertext  secure  IBE  system  (in  the  sense  of  Section  2)  in  the  random  oracle 
model.  Let  6  be  a  probabilistic  public  key  encryption  scheme.  We  denote  by  £pfc(M;  r)  the  encryption 
of  M  using  the  random  bits  r  under  the  public  key  pk.  Fujisaki-Okamoto  define  the  hybrid  scheme  £hy 
as: 

£$(M)  =  (£pk(a;H3(a,M))\  H4(a)  ©  M  ) 

Here  a  is  generated  at  random  and  H^,H^  are  cryptographic  hash  functions.  Fujisaki-Okamoto  show 
that  if  £  is  a  one-way  encryption  scheme  then  £hy  is  a  chosen  ciphertext  secure  system  (IND-CCA)  in  the 
random  oracle  model  (assuming  £pk  satisfies  some  natural  constraints).  We  note  that  semantic  security 
implies  one-way  encryption  and  hence  the  Fujisaki-Okamoto  result  also  applies  if  £  is  semantically 
secure  (IND-CPA). 

We  apply  the  Fujisaki-Okamoto  transformation  to  Basicldent  and  show  that  the  resulting  IBE 
system  is  IND-ID-CCA  secure.  We  obtain  the  following  IBE  scheme  which  we  call  Fullldent.  Recall  that 
n  is  the  length  of  the  message  to  be  encrypted. 

Setup:  As  in  the  Basicldent  scheme.  In  addition,  we  pick  a  hash  function  H3  :  {0,  l}n  x  {0,  l}n  — ►  Z*, 
and  a  hash  function  H4  :  {0,  l}n  — ►  {0,  l}n. 

Extract:  As  in  the  Basicldent  scheme. 
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Encrypt:  To  encrypt  M  6  {0, l}n  under  the  public  key  ID  do  the  following:  (1)  compute  Qm  = 
-ffi(ID)  €  G*,  (2)  choose  a  random  a  G  {0,  l}n,  (3)  set  r  =  H-^{a,  M ),  and  (4)  set  the  ciphertext  to  be 

C  =  (rP,  <7®H2(g{D),  M®H4(cr))  where  gm  =  e(QlD,  Ppub)  £  G2 

Decrypt:  Let  C  =  (U,  V,  W)  be  a  ciphertext  encrypted  using  the  public  key  ID.  If  JJ  ^  G*  reject  the 
ciphertext.  To  decrypt  C  using  the  private  key  dm  G  Gf  do: 

1.  Compute  V  ©  H2{e(dm ,  U))  =  a. 

2.  Compute  W  ©  H±{a)  =  M. 

3.  Set  r  =  H^(a,M).  Test  that  U  =  rP.  If  not,  reject  the  ciphertext. 

4.  Output  M  as  the  decryption  of  C. 

This  completes  the  description  of  Fullldent.  Note  that  M  is  encrypted  as  W  =  M ©//4(a).  This  can  be 
replaced  by  W  =  where  E  is  a  semantically  secure  symmetric  encryption  scheme  (see  [16]). 

Security.  The  following  theorem  shows  that  Fullldent  is  a  chosen  ciphertext  secure  IBE  (i.e.  IND-ID- 
CCA),  assuming  BDH  is  hard  in  groups  generated  by  Q. 

Theorem  4.4.  Let  the  hash  functions  Hi,  H-2,  H%,  be  random  oracles.  Then  Fullldent  is  a  chosen 
ciphertext  secure  IBE  (iND-ID-CCAj  assuming  BDH  is  hard  in  groups  generated  by  Q . 

Concretely,  suppose  there  is  an  IND-ID-CCA  adversary  A  that  has  advantage  e(k)  against  the  scheme 
Fullldent  and  A  runs  in  time  at  most  t(k).  Suppose  A  makes  at  most  qE  extraction  queries,  at  most 
qD  decryption  queries,  and  at  most  qH2,  Qh3,  Qh4  queries  to  the  hash  functions  H2,H^,,Hi  respectively. 
Then  there  is  a  BDH  algorithm  B  for  Q  with  running  time  t\(k)  where: 

Advgfi(k)  >  2 FOadv(e(1+e^+qD),  qH4,  qH3,  qD)/qH2 

h(k)  <  FOtime(t(k),qH4,qH  3) 

where  the  functions  FOtime  and  FOadv  are  defined  in  Theorem  f.5. 

The  proof  of  Theorem  4.4  is  based  on  the  following  result  of  Fujisaki  and  Okanroto  (Theorem  14 
in  [16]).  Let  BasicPut/'^  be  the  result  of  applying  the  Fujisaki-Okanroto  transformation  to  BasicPub. 
Theorem  4.5  (Fujisaki-Okamoto).  Suppose  A  is  an  IND-CCA  adversary  that  achieves  advantage 
e(k)  when  attacking  BasicPub^.  Suppose  A  has  running  time  t(k),  makes  at  most  qD  decryption 
queries,  and  makes  at  most  qH3,qH4  queries  to  the  hash  functions  Hj,,Hi  respectively.  Then  there  is  an 
IND-CPA  adversary  B  against  BasicPub  with  running  time  t\{k)  and  advantage  e\ (k)  where 

ei{k)  >  FOadv(e(k),qH4,qH3,qD)  =  — - - r  [(e(k)  +  1)(1  -  2/q)qD  -  1] 

z\Qh4  -F  1h3 ) 

h(k)  <  F0ume(t(k),qHi,qH3)  =  t(k)  +  0((qHi  +  qH3)  ■  n),  and 

Here  q  is  the  size  of  the  groups  Gi,G2  and  n  is  the  length  of  a. 

In  fact,  Fujisaki-Okamoto  prove  a  stronger  result:  Under  the  hypothesis  of  Theorem  4.5,  BasicPub/ty 
would  not  even  be  a  one-way  encryption  scheme.  For  our  purposes  the  result  in  Theorem  4.5  is  sufficient. 
To  prove  Theorem  4.4  we  also  need  the  following  lemma  to  translate  between  an  IND-ID-CCA  chosen 
ciphertext  attack  on  Fullldent  and  an  IND-CCA  chosen  ciphertext  attack  on  BasicPubfty. 

Lemma  4.6.  Let  A  be  an  IND-ID-CCA  adversary  that  has  advantage  e(k)  against  Fullldent.  Suppose  A 
makes  at  most  qE  >  0  private  key  extraction  queries  and  at  most  qD  decryption  queries.  Then  there  is 
an  IND-CCA  adversary  B  that  has  advantage  at  least  e(1+qg+g£>)  a9a^nsl  BasicPub^.  Its  running  time 
is  0(time(A)). 
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Proof.  We  construct  an  IND-CCA  adversary  B  that  uses  A  to  gain  advantage  e/e(l  +  qE  +  qD) 
against  BasicPub/ty.  The  game  between  the  challenger  and  the  adversary  B  starts  with  the  challenger 
first  generating  a  random  public  key  by  running  algorithm  keygen  of  BasicPub^A  The  result  is  a  public 
key  Kpub  =  ( q ,  Gi,  G2,  e,  n,  P,  Ppub:  Q\d,  H-2,  H3,  HQ  and  a  private  key  dID  =  sQ ,D.  The  challenger  gives 
Kpub  to  algorithm  B. 

Algorithm  B  mounts  an  IND-CCA  attack  on  the  key  Kpu b  using  the  help  of  algorithm  A.  Algorithm  B 
interacts  with  A  as  follows: 

Setup:  Same  as  in  Lemma  4.2  (with  #3,774  included  in  the  system  parameters  given  to  A). 
ip-queries:  These  queries  are  handled  as  in  Lemma  4.2. 

Phase  1:  Private  key  queries.  Handled  as  in  Lemma  4.2. 

Phase  1:  Decryption  queries.  Let  (ID*,C*)  be  a  decryption  query  issued  by  algorithm  A.  Let 
C*  =  (Ui,  Vi,  Wi).  Algorithm  B  responds  to  this  query  as  follows: 

1.  Run  the  above  algorithm  for  responding  to  ip-queries  to  obtain  a  Qi  £  G^  such  that  ip(ID,;)  =  Qi. 
Let  (ID i,Qi,bi,coirii)  be  the  corresponding  tuple  on  the  H\lst. 

2.  Suppose  coirii  =  0.  In  this  case  run  the  algorithm  for  responding  to  private  key  queries  to  obtain 
the  private  key  for  the  public  key  ID,;.  Then  use  the  private  key  to  respond  to  the  decryption 
query. 

3.  Suppose  coirii  =  L  Then  Qi  =  biQm. 

-  Recall  that  Ui  £  Gi.  Set  C[  =  (6*17*,  V*,  Wi).  Let  <7,  =  sQi  be  the  (unknown)  Fullldent 
private  key  corresponding  to  ID*.  Then  the  Fullldent  decryption  of  C*  using  <7,  is  the  same  as 
the  BasicPubfe?;  decryption  of  C[  using  dID.  To  see  this  observe  that: 

e(biUi,dID )  =  e(biUi,sQm )  =  e(t/*,  s6*Q,D)  =  e(t/*,sQ*)  =  e(P*,p). 

-  Relay  the  decryption  query  (C))  to  the  challenger  and  relay  the  challenger’s  response  back  to  A. 

Challenge:  Once  algorithm  A  decides  that  Phase  1  is  over  it  outputs  a  public  key  IDC^  and  two 
messages  Mo,  Mi  on  which  it  wishes  to  be  challenged.  Algorithm  B  responds  as  follows: 

1.  Algorithm  B  gives  the  challenger  Mo,  Mi  as  the  messages  that  it  wishes  to  be  challenged  on.  The 
challenger  responds  with  a  BasicPubftj/  ciphertext  C  =  ( U ,  V,  W)  such  that  C  is  the  encryption  of 
Mc  for  a  random  c  £  {0, 1}. 

2.  Next,  B  runs  the  algorithm  for  responding  to  Hi-queries  to  obtain  a  Q  £  G^  such  that  77i(IDc/j)  = 
Q.  Let  (IDch,  Q,  b,  coin )  be  the  corresponding  tuple  on  the  H[lst.  If  coin  =  0  then  B  reports  failure 
and  terminates.  The  attack  on  BasicPubfe2/  failed. 

3.  We  know  coin  =  1  and  therefore  Q  =  bQ ,D.  Recall  that  when  C  =  (U,V,W)  we  have  U  £  G^. 
Set  C  =  (b ~1U,  V,  W),  where  b~1  is  the  inverse  of  b  mod  q.  Algorithm  B  responds  to  A  with  the 
challenge  C' .  Note  that,  as  in  the  proof  of  Lemma  4.2,  C'  is  a  Fullldent  encryption  of  Mc  under 
the  public  key  IDC^  as  required. 

Phase  2:  Private  key  queries.  Algorithm  B  responds  to  private  key  extraction  queries  in  the  same 
way  it  did  in  Phase  1. 

Phase  2:  Decryption  queries.  Algorithm  B  responds  to  decryption  queries  in  the  same  way  it 
did  in  Phase  1.  However,  if  the  resulting  decryption  query  relayed  to  the  challenger  is  equal  to  the 
challenge  ciphertext  C  =  ( U ,  V,  W)  then  B  reports  failure  and  terminates.  The  attack  on  BasicPubft?/ 
failed. 
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Guess:  Eventually  algorithm  A  outputs  a  guess  c'  for  c.  Algorithm  B  outputs  d  as  its  guess  for  c. 

Claim:  If  algorithm  B  does  not  abort  during  the  simulation  then  algorithm  Pi’s  view  is  identical  to 

its  view  in  the  real  attack.  Furthermore,  if  B  does  not  abort  then  |  Pr[c  =  c'}  —  ^  |  >  e.  The  probability 
is  over  the  random  bits  used  by  A,  B  and  the  challenger. 

Proof  of  claim.  The  responses  to  IT -queries  are  as  in  the  real  attack  since  each  response  is  uniformly 
and  independently  distributed  in  G*.  All  responses  to  private  key  extraction  queries  and  decryp¬ 
tion  queries  are  valid.  Finally,  the  challenge  ciphertext  C'  given  to  A  is  the  Full Ident  encryption  of  Mc 
for  some  random  c  E  {0, 1}.  Therefore,  by  definition  of  algorithm  A  we  have  that  |  Pr[c  =  c']  —  ||  >  e.  □ 

It  remains  to  bound  the  probability  that  algorithm  B  aborts  during  the  simulation.  The  algorithm 
could  abort  for  three  reasons:  (1)  a  bad  private  key  query  from  A  during  phases  1  or  2,  (2)  A  chooses 
a  bad  ID^  to  be  challenged  on,  or  (3)  a  bad  decryption  query  from  A  during  phase  2.  We  define  three 
corresponding  events: 

£i  is  the  event  that  A  issues  a  private  key  query  during  phase  1  or  2  that  causes  algorithm  B  to  abort. 
£■2  is  the  event  that  A  choose  a  public  key  IDc/i  to  be  challenged  on  that  causes  algorithm  B  to  abort. 
£3  is  the  event  that  during  phase  2  of  the  simulation  Algorithm  A  issues  a  decryption  query  (ID;,  (7;) 
so  that  the  decryption  query  that  B  would  relay  to  the  BasicPub/,:v  challenger  is  equal  to  C.  Recall 
that  C  =  ( U,V,W )  is  the  challenge  ciphertext  from  the  BasicPut/ty  challenger. 

Claim:  Pr[-i£i  A  ->£2  A  ^£3]  >  5qE+qD  {1  —  5) 

Proof  of  claim.  We  prove  the  claim  by  induction  on  the  maximum  number  of  queries  qE  +  qD  made 
by  the  adversary.  Let  i  =  qE  +  qD  and  let  £0'"*  be  the  event  that  £\  V  £3  happens  after  A  issues  at 
most  i  queries.  Similarly,  let  £l  be  the  event  that  £\  V  £3  happens  for  the  first  time  when  A  issues 
the  Pth  query.  We  prove  by  induction  on  i  that  Pr[-i£0"'*  |  — '£’2]  >  Si.  The  claim  follows  because 
Pr[-i£i  A  £2  A  -^£3]  =  Pr[^£i  A  ^£3  |  —■£^2]  Pr[ — '^2]  >  Pr[-i£i  A  ->£3  |  — '<£’2]  (1  —  £)• 

For  i  =  0  the  claim  is  trivial  since  by  definition  Pr[-i£°"'°]  =  1.  Now,  suppose  the  claim  holds  for 
i  —  1.  Then 

Pr[^£0'"*  |  ^£2]  =  Pr[-i£0"'*  |  -,£°  -i~1  A  £2\  Pr^f0-*-1  |  £2 ] 

=  Pr[-n£*  |  -if0-*-1  A  -£2]  Prh£°-*_1  |  -£2]  >  Pr[-.£*  |  ^£°-i~1  A  -£2]<5*_1 

Hence,  it  suffices  to  bound  qi  =  Pr[-i£*  |  -i£°--*_1  A  — >£2]  -  In  other  words,  we  bound  the  probability 
that  the  Pth  query  does  not  cause  £*  to  happen  given  that  the  first  i  —  1  queries  did  not,  and  given 
that  £2  does  not  occur.  Consider  the  Pth  query  issued  by  A  during  the  simulation.  The  query  is  either 
a  private  key  query  for  (ID.;)  or  a  decryption  query  for  (ID;,  (7;)  where  C;  =  (I/;,  V;,  W;}.  If  the  query  is 
a  decryption  query  we  assume  it  takes  place  during  phase  2  since  otherwise  it  has  no  effect  on  £3. 

Let  Hi(ID;)  =  Qi  and  let  (ID;, Q;, 6;, com;)  be  the  corresponding  tuple  on  the  H[lst.  Recall  that 
when  coirii  =  0  the  query  cannot  cause  event  £1  to  happen.  Similarly,  when  coin;  =  0  the  query  cannot 
cause  event  £3  to  happen  since  in  this  case  B  does  not  relay  a  decryption  query  to  the  BasicPub/ty 
challenger.  We  use  these  facts  to  bound  qi.  There  are  four  cases  to  consider.  In  the  first  three  cases 
we  assume  ID;  is  not  equal  to  the  public  key  IDc/j  on  which  A  is  being  challenged. 

Case  1.  The  Pth  query  is  the  first  time  A  issues  a  query  containing  ID;.  In  this  case  Pr[com;  =  0]  =  5 
and  hence  qi  >  6. 

Case  2.  The  public  key  ID;  appeared  in  a  previous  private  key  query.  Since  by  assumption  this  earlier 
private  key  query  did  not  cause  to  happen  we  know  that  coin;  =  0.  Hence,  we  have  qt  =  1. 
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Case  3.  The  public  key  ID;  appeared  in  a  previous  decryption  query.  Since  by  assumption  this  earlier 
decryption  query  did  not  cause  event  to  happen  we  have  that  either  coirii  =  0  or  coin;  is 

independent  of  *4’s  current  view.  Either  way  we  have  that  g;  >  S. 

Case  4.  The  public  key  ID;  is  equal  to  the  public  key  ID ch  on  which  A  is  being  challenged.  Then,  by 
definition,  the  i’th  query  cannot  be  a  private  key  query.  Therefore,  it  must  be  a  decryption  query 
(ID;  ,  Ci).  Furthermore,  since  £ 2  did  not  happen  we  know  that  coin;  =  1  and  hence  B  will  relay  a 
decryption  query  C[  to  the  BasicPub^  challenger.  Let  C'  be  the  challenge  ciphertext  given  to  A. 
By  definition  we  know  that  C;  7^  C' .  It  follows  that  C\  7^  C.  Therefore  this  query  cannot  cause 
event  £3  to  happen.  Hence,  in  this  case  g;  =  1. 

To  summarize,  we  see  that  whatever  the  i’th  query  is,  we  have  that  g;  >  5.  Therefore,  we  have  that 
Pr[-i£0'"*  |  -.f2]  >  5l  as  required.  The  claim  now  follows  by  setting  i  =  qE  +  qD-  □ 

To  conclude  the  proof  of  Lemma  4.6  it  remains  to  optimize  the  choice  of  5.  Since  Pr[-i£i  A  —>£ 2  A  —£3]  > 
5qE+qD —  the  success  probability  is  maximized  at  5opt  =  1  —  l/(qE+qD  +  l).  Using  5opt,  the  probabil¬ 
ity  that  B  does  not  abort  is  at  least  e(i+qE+qD)  •  This  shows  that  £>’ s  advantage  is  at  least  e/e(l+gB+gD) 
as  required.  □ 

Proof  of  Theorem  4.4.  By  Lemma  4.6  an  IND-ID-CCA  adversary  on  Fullldent  implies  an  IND-CCA 
adversary  on  BasicPub^.  By  Theorem  4.5  an  IND-CCA  adversary  on  BasicPub^  implies  an  IND-CPA 
adversary  on  BasicPub.  By  Lemma  4.3  an  IND-CPA  adversary  on  BasicPub  implies  an  algorithm  for 
BDH.  Composing  all  these  reductions  gives  the  required  bounds.  □ 


4.3  Relaxing  the  hashing  requirements 

Recall  that  the  IBE  system  of  Section  4.2  uses  a  hash  function  H\  :  {0, 1}*  — >  G^.  The  concrete  IBE 
system  presented  in  the  next  section  uses  Gi  as  a  subgroup  of  the  group  of  points  on  an  elliptic  curve. 
In  practice,  it  is  difficult  to  build  hash  functions  that  hash  directly  onto  such  groups.  We  therefore 
show  how  to  relax  the  requirement  of  hashing  directly  onto  G^.  Rather  than  hash  onto  G^  we  hash 
onto  some  set  A  C  {0, 1}*  and  then  use  a  deterministic  encoding  function  to  map  A  onto  G^. 

Admissible  encodings:  Let  Gi  be  a  group  and  let  A  £  {0, 1}*  be  a  finite  set.  We  say  that  an 
encoding  function  L  :  A  — >  G^  is  admissible  if  it  satisfies  the  following  properties: 

1.  Computable:  There  is  an  efficient  deterministic  algorithm  to  compute  L(x)  for  any  x  £  A. 

2.  f-to-1:  For  any  1/  6  Gj  the  preimage  of  y  under  L  has  size  exactly  i.  In  other  words,  |L-1(y)|  =  t 
for  all  y  £  G^.  Note  that  this  implies  that  |A|  =  l  ■  |GJ | . 

3.  Samplable:  There  is  an  efficient  randomized  algorithm  Cg  such  that  Cs(y)  induces  a  uniform 
distribution  on  L-1(y)  for  any  y  £  G*.  In  other  words,  Cs{u)  is  a  uniform  random  element  in 

We  slightly  modify  Fullldent  to  obtain  an  IND-ID-CCA  secure  IBE  system  where  H\  is  replaced  by  a 
hash  function  into  some  set  A.  Since  the  change  is  so  minor  we  refer  to  this  new  scheme  as  Fullldent’: 

Setup:  As  in  the  Fullldent  scheme.  The  only  difference  is  that  H 1  is  replaced  by  a  hash  function 
H[  :  {0, 1}*  — ►  A.  The  system  parameters  also  include  a  description  of  an  admissible  encoding 
function  L  :  A  — >  G^ . 
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Extract,  Encrypt:  As  in  the  Fullldent  scheme.  The  only  difference  is  that  in  Step  1  these  algorithms 
compute  Q\D  =  L(H[{ ID))  G  G*. 

Decrypt:  As  in  the  Fullldent  scheme. 

This  completes  the  description  of  Fullldent’.  The  following  theorem  shows  that  Fullldent’  is  a  chosen 
ciphertext  secure  IBE  (i.e.  IND-ID-CCA),  assuming  Fullldent  is. 

Theorem  4.7.  Let  A  be  an  IND-ID-CCA  adversary  on  Fullldent’  that  achieves  advantage  e(k).  Suppose 
A  makes  at  most  qHl  queries  to  the  hash  function  H[.  Then  there  is  an  IND-ID-CCA  adversary  B  on 
Fullldent  that  achieves  the  same  advantage  e(k)  and  time(B)  =  time(A)  +  qHl  ■  time(Ls) 

Proof  Sketch.  Algorithm  B  attacks  Fullldent  by  running  algorithm  A.  It  relays  all  decryption 
queries,  extraction  queries,  and  hash  queries  from  A  directly  to  the  challenger  and  relays  the  challenger’s 
response  back  to  A.  It  only  behaves  differently  when  A  issues  a  hash  query  to  H[.  Recall  that  B  only 
has  access  to  a  hash  function  Hi  :  {0, 1}*  — »  G*.  To  respond  to  H[  queries  algorithm  B  maintains  a  list 
of  tuples  (ID j,yj)  as  explained  below.  We  refer  to  this  list  as  the  ( H[)hst .  The  list  is  initially  empty. 
When  A  queries  the  oracle  H[  at  a  point  ID,  algorithm  B  responds  as  follows: 

1.  If  the  query  ID,;  already  appears  on  the  (H[)hst  in  a  tuple  (IDj,yj),  respond  with  iL((ID,;)  =  y,  G  A. 

2.  Otherwise,  B  issues  a  query  for  L/i(ID,).  Say,  f4i(ID,;)  =  a  G  G*. 

3.  B  runs  the  sampling  algorithm  £5(0)  to  generate  a  random  element  y  G  L~1(a). 

4.  B  adds  the  tuple  (IDj,y)  to  the  ( H[)hst  and  responds  to  A  with  i4((ID,)  =  y  G  A.  Note  that  y  is 
uniformly  distributed  in  A  as  required  since  a  is  uniformly  distributed  in  G*  and  L  is  an  f-to-1  map. 

Algorithm  £>’ s  responses  to  all  of  A’s  queries,  including  H[  queries,  are  identical  to  A’s  view  in  the  real 
attack.  Hence,  B  will  have  the  same  advantage  e(k)  in  winning  the  game  with  the  challenger.  □ 


5  A  concrete  IBE  system  using  the  Weil  pairing 

In  this  section  we  use  Fullldent’  to  describe  a  concrete  IBE  system  based  on  the  Weil  pairing.  We  first 
review  some  properties  of  the  pairing  (see  the  Appendix  for  more  details). 

5.1  Properties  of  the  Weil  Pairing 

Let  p  be  a  prime  satisfying  p  =  2  mod  3  and  let  q  >  3  be  some  prime  factor  of  p  +  1.  Let  E  be  the 
elliptic  curve  defined  by  the  equation  y'2  =  x3  +  1  over  Fp.  We  state  a  few  elementary  facts  about  this 
curve  E  (see  [43]  for  more  information).  From  here  on  we  let  E(¥pr)  denote  the  group  of  points  on  E 
defined  over  Fpr. 

Fact  1:  Since  x3  +  1  is  a  permutation  on  ¥p  it  follows  that  the  group  E(¥p)  contains  p  +  1  points.  We 
let  O  denote  the  point  at  infinity.  Let  P  G  E(¥p)  be  a  point  of  order  q  and  let  Gi  be  the  subgroup 
of  points  generated  by  P. 

Fact  2:  For  any  yo  G  Fp  there  is  a  unique  point  (xo,yo)  on  E( Fp),  namely  Xo  =  (yj)  —  1)1//3  G  Fp. 
Hence,  if  (x,  y)  is  a  random  non-zero  point  on  E(¥p)  then  y  is  uniform  in  Fp.  We  use  this  property 
to  build  a  simple  admissible  encoding  function. 

Fact  3:  Let  1  /  (  G  Fp2  be  a  solution  of  x3  —  1  =  0  in  Fp2.  Then  the  map  (f(x,y)  =  ((x.  y)  is  an 
automorphism  of  the  group  of  points  on  the  curve  E.  Note  that  for  any  point  Q  =  (x,y)  G  E( Fp) 
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we  have  that  4>(Q)  G  E(¥p2),  but  c/)(Q)  0  E(Wp).  Hence,  Q  G  E(¥p)  is  linearly  independent  of 
o(Q)  g  E(¥p2). 

Fact  4:  Since  the  points  PgGi  and  <^>(-P)  are  linearly  independent  they  generate  a  group  isomorphic 
to  Zq  x  Zq.  We  denote  this  group  of  points  by  E[q\. 

Let  O2  be  the  subgroup  of  F*2  of  order  q.  The  Weil  pairing  on  the  curve  E(¥p 2)  is  a  mapping 
e  :  E[q]  x  E[q]  — ►  G2  defined  in  the  Appendix.  For  any  Q,R  £  E(¥p)  the  Weil  pairing  satisfies 
e(Q,R)  =  1.  In  other  words,  the  Weil  pairing  is  degenerate  on  E(¥p),  and  hence  degenerate  on  the 
group  G] .  To  get  a  non-degenerate  map  we  define  the  modified  Weil  pairing  e  :  Gi  x  Gi  —*■  G2  as 
follows: 

i(P,Q)  =  e(P,</>(Q)) 

The  modified  Weil  pairing  satisfies  the  following  properties: 

1.  Bilinear:  For  all  P,  Q  G  Gi  and  for  all  a,  b  G  Z  we  have  e(aP ,  bQ )  =  e(P,  Q)ab. 

2.  Non-degenerate:  If  P  is  a  generator  of  Gi  then  e(P,  P)  G  F*2  is  a  generator  of  G2. 

3.  Computable:  Given  P,  Q  G  Gi  there  is  an  efficient  algorithm,  due  to  Miller,  to  compute  e(P,  Q)  G  G2. 
This  algorithm  is  described  in  the  Appendix.  Its  running  time  is  comparable  to  exponentiation  in 

Fp. 

Joux  and  Nguyen  [28]  point  out  that  although  the  Computational  Diffie-Hellman  problem  (CDH) 
appears  to  be  hard  in  the  group  Gi,  the  Decisional  Diffie-Hellman  problem  (DDH)  is  easy  in  Gi  (as 
discussed  in  Section  3). 

BDH  Parameter  Generator  Q\ :  Given  a  security  parameter  2  <  k  G  Z  the  BDH  parameter 
generator  picks  a  random  fc-bit  prime  q  and  finds  the  smallest  prime  p  such  that  (1)  p  =  2  mod  3,  (2) 
q  divides  p  +  1,  and  (3)  q2  does  not  divide  p  +  1.  We  write  p  =  Iq  +  1.  The  group  Gi  is  the  subgroup 

of  order  q  of  the  group  of  points  on  the  curve  y 2  =  x3  +  1  over  ¥p.  The  group  G2  is  the  subgroup  of 

order  q  of  F*2.  The  bilinear  map  e  :  Gi  x  Gi  — ►  G2  is  the  modified  Weil  pairing  defined  above. 

The  BDH  parameter  generator  Q\  is  believed  to  satisfy  the  BDH  assumption  asymptotically.  How¬ 
ever,  there  is  still  the  question  of  what  values  of  p  and  q  can  be  used  in  practice  to  make  the  BDH 
problem  sufficiently  hard.  At  the  very  least,  we  must  ensure  that  the  discrete  log  problem  in  Gi  is 
sufficiently  hard.  As  pointed  out  in  Section  3  the  discrete  log  problem  in  Gi  is  efficiently  reducible 
to  discrete  log  in  G2  (see  [32,  17]).  Hence,  computing  discrete  log  in  F*2  is  sufficient  for  computing 
discrete  log  in  Gi.  In  practice,  for  proper  security  of  discrete  log  in  IF*2  one  often  uses  primes  p  that 
are  at  least  512-bits  long  (so  that  the  group  size  is  at  least  1024-bits  long).  Consequently,  one  should 
not  use  this  BDH  parameter  generator  with  primes  p  that  are  less  than  512-bits  long. 

5.2  An  admissible  encoding  function:  MapToPoint 

Let  Gi,G2  be  two  groups  generated  by  Q\  as  defined  above.  Recall  that  the  IBE  system  of  Section 

4.2  uses  a  hash  function  H\  :  {0,1}*  — >  G{.  By  Theorem  4.7,  it  suffices  to  have  a  hash  function 
H 1  :  {0, 1}*  — >  A  for  some  set  A,  and  an  admissible  encoding  function  L  :  A  — >  G{.  In  what  follows 
the  set  A  will  be  and  the  admissible  encoding  function  L  will  be  called  MapToPoint. 

Let  p  be  a  prime  satisfying  p  =  2  mod  3  and  p  =  tq  —  1  for  some  prime  q  >  3.  We  require  that  q  does 
not  divide  l  (i.e.  that  q2  does  not  divide  p+  1).  Let  E  be  the  elliptic  curve  y 2  =  x3  + 1  over  ¥p.  Let  Gi 
be  the  subgroup  of  points  on  E  of  order  q.  Suppose  we  already  have  a  hash  function  H 1  :  {0, 1}*  — >  Fp. 
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Algorithm  MapToPoint  works  as  follows  on  input  yo  £  Fp: 

1.  Compute  xo  =  (y$  —  l)1/3  =  (y$  —  1)(2p-1)/3  £  Fp. 

2.  Let  Q  =  (xq.  yo)  £  E( Fp)  and  set  Qm  =  £Q  £  Gi. 

3.  Output  MapToPoint(yo)  =  Qm. 

This  completes  the  description  of  MapToPoint. 

We  note  that  there  are  £  —  1  values  of  yo  £  Fp  for  which  £Q  =  £(xq,  yo)  =  O  (these  are  the  non-0 
points  of  order  dividing  £).  Let  B  C  Fp  be  the  set  of  these  yo-  When  Hi  (ID)  is  one  of  these  i—\  values 
Qm  is  the  identity  element  of  Gi.  It  is  extremely  unlikely  for  Hi(ID)  to  hit  one  of  these  points  -  the 
probability  is  1/q  <  l/2k.  Hence,  for  simplicity  we  say  that  Hi  (ID)  only  outputs  elements  in  ¥p  \  B, 
i.e.  H i  :  {0, 1}*  — >  Fp  \  H.  Algorithm  MapToPoint  can  be  easily  extended  to  handle  the  values  yo  £  B 
by  hashing  ID  multiple  times  using  different  hash  functions. 

Lemma  5.1.  MapToPoint  :  Fp  \  B  — ►  G*  is  an  admissible  encoding  function. 

Proof.  The  map  is  clearly  computable  and  is  a  £  —  to  —  1  mapping.  It  remains  to  show  that  L 
is  samplable.  Let  P  be  a  generator  of  E(¥p).  Given  a  Q  £  G(  the  sampling  algorithm  C$  does  the 
following:  (1)  pick  a  random  b  £  {0, ...  ,£  —  1},  (2)  compute  Q'  =  £~l  •  Q  +  bqP  =  (x,y),  and  (3) 
output  Cs(Q)  =  y  £  ¥p.  Here  H1  is  the  inverse  of  £  in  Z*.  This  algorithm  outputs  a  random  element 
from  the  £  elements  in  MapToPoint_1(Q)  as  required.  □ 


5.3  A  concrete  IBE  system 

Using  Fullldent’  from  Section  4.3  with  the  BDH  parameter  generator  Q\  and  the  admissible  encoding 
function  MapToPoint  we  obtain  a  concrete  IBE  system.  Note  that  in  this  system,  H\  is  a  hash  function 
from  {0, 1}*  to  Fp  (where  p  is  the  finite  field  output  by  Gi)-  The  security  of  the  system  follows  directly 
from  Theorem  4.4  and  Theorem  4.7.  We  summarize  this  in  the  following  corollary. 

Corollary  5.2.  The  IBE  system  Fullldent’  using  the  BDH  parameter  generator  G\  and  the  admissible 
encoding  MapToPoint  is  a  chosen  ciphertext  secure  IBE  (i.e.  IND-ID-CCA  in  the  random  oracle  model) 
assuming  Gi  satisfies  the  BDH  assumption. 

Performance.  Algorithms  Setup  and  Extract  are  very  simple.  At  the  heart  of  both  algorithms  is  a 
standard  multiplication  on  the  curve  H(Fp).  Algorithm  Encrypt  requires  that  the  encryptor  compute  the 
Weil  pairing  of  Qm  and  Ppub-  Note  that  this  computation  is  independent  of  the  message  to  be  encrypted, 
and  hence  can  be  done  once  and  for  all.  Once  gm  is  computed  the  performance  of  the  system  is  almost 
identical  to  standard  ElGamal  encryption.  Decryption  is  a  single  Weil  pairing  computation.  We  note 
that  the  ciphertext  length  of  Basicldent  using  Gi  is  the  same  as  in  regular  ElGamal  encryption  in  Fp. 


6  Extensions  and  Observations 

Tate  pairing  and  other  curves.  Our  IBE  system  works  with  any  efficiently  computable  bilinear 
pairing  e  :  Gi  x  Gi  — ►  G2  between  two  groups  Gi,G2  as  long  as  the  BDH  assumption  holds.  Many 
different  curves,  or  more  generally  Abelian  varieties,  are  believed  to  give  rise  to  such  maps.  For 
example,  one  could  use  the  curve  y 2  =  x3  +  x  over  Fp  with  p  =  3  mod  4  and  its  endomorphism 
4>  :  (x,y)  — ►  (— x,iy )  where  i2  =  —1.  As  another  example,  Galbraith  [18]  suggests  using  supersingular 
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elliptic  curves  over  a  field  of  small  characteristic  to  reduce  the  ciphertext  size  in  our  system.  More 
general  Abelian  varieties  are  proposed  by  Rubin  and  Silverberg  [39].  We  note  that  both  encryption 
and  decryption  in  Fullldent  can  be  made  faster  by  using  the  Tate  pairing  on  elliptic  curves  rather 
than  the  Weil  pairing  [19,  1]. 

Asymmetric  pairings.  Our  IBE  system  can  use  slightly  more  general  bilinear  maps,  namely  maps  of 
the  form  e  :  Go  x  Gi  — ►  G2  where  Go,  Gi,  G2  are  three  groups  of  prime  order  q.  Using  the  notation  of 
Section  4.1  the  only  change  to  Basicldent  is  that  we  take  P  and  Ppub  as  elements  in  Go  and  let  H\  be 
a  hash  function  H 1  :  {0, 1}*  — >  G*.  Everything  else  remains  the  same.  However,  to  make  the  proof 
of  security  go  through  (Lemma  4.2  in  particular)  we  need  a  different  complexity  assumption  which 
we  call  the  co-BDH  assumption:  given  random  P,  aP,  bP  £  Go  and  Q,  aQ ,  cQ  £  Gi  no  polynomial 
time  algorithm  can  compute  e(P,  Q)abc  with  non-negligible  probability.  If  one  is  willing  to  accept  this 
assumption  then  we  can  avoid  using  supersingular  curves  and  instead  use  elliptic  curves  over  Fp,  p  >  3 
proposed  by  Miyaji  et  al.  [35].  Curves  E/¥p  in  this  family  are  not  supersingular  and  have  the  property 
that  if  q  divides  \E(Fp)\  then  E[q\  C  E{Fp&)  (recall  that  E[q]  is  the  group  containing  all  point  in  E  of 
order  dividing  q).  One  way  to  use  these  curves  is  to  set  Gi  to  be  a  cyclic  subgroup  of  E(¥p)  of  order 
q  and  Go  to  be  a  different  cyclic  subgroup  of  E(¥pe)  of  the  same  order  q.  The  standard  Weil  or  Tate 
pairings  on  Go  x  Gi  can  be  used  as  the  bilinear  map  e.  Note  that  hashing  public  keys  onto  Gi  C  E{¥p) 
is  easily  done.  Alternatively,  to  reduce  the  ciphertext  size  (which  contains  an  element  from  Go)  one 
could  take  Go  as  a  subgroup  of  order  q  of  E(¥p)  and  Gi  as  a  different  subgroup  of  E(¥p 6)  of  the  same 
order.  The  question  is  how  to  hash  public  keys  into  Gi.  To  do  so,  let  tr  :  E(¥p Q  — >  E(¥p)  be  the 
trace  map  on  the  curve  and  define  Gi  to  be  the  subgroup  of  E[q\  containing  all  points  P  whose  trace 
is  O,  i.e.,  tr(P)  =  O.  Then  given  a  hash  function  H  :  {0, 1}*  — >  E\q\  we  can  hash  a  public  key  ID 
into  Gi  by  computing:  Hi(ID)  =  6iL(ID)  —  tr(Lf(ID))  £  Gi.  Finally,  we  note  that  by  modifying  the 
security  proof  appropriately  one  can  take  Gi  =  E[q]  (a  non-cyclic  group)  and  then  avoid  computing 
traces  while  hashing  into  Gi  (see  also  [18]). 

Distributed  PKG.  In  the  standard  use  of  an  IBE  in  an  e-mail  system  the  master-key  stored  at  the  PKG 
must  be  protected  in  the  same  way  that  the  private  key  of  a  CA  is  protected.  One  way  of  protecting 
this  key  is  by  distributing  it  among  different  sites  using  techniques  of  threshold  cryptography  [20]. 
Our  IBE  system  supports  this  in  a  very  efficient  and  robust  way.  Recall  that  the  master-key  is  some 
s  £  Z*.  in  order  to  generate  a  private  key  the  PKG  computes  Qpriv  =  sQ !D,  where  Q ,D  is  derived 
from  the  user’s  public  key  ID.  This  can  easily  be  distributed  in  a  f-out-of-n  fashion  by  giving  each 

of  the  n  PKGs  one  share  Si  of  a  Shamir  secret  sharing  of  s  mod  q.  When  generating  a  private  key 

(i) 

each  of  the  t  chosen  PKGs  simply  responds  with  QrQv  =  SiQ !D.  The  user  can  then  construct  Qpriv 
as  Qpriv  =  ^iQpriv  where  the  A,;’s  are  the  appropriate  Lagrange  coefficients. 

Furthermore,  it  is  easy  to  make  this  scheme  robust  against  dishonest  PKGs  using  the  fact  that  DDH 

(i) 

is  easy  in  Gi.  During  setup  each  of  the  n  PKGs  publishes  Ppub  =  SjP.  During  a  key  generation 
request  the  user  can  verify  that  the  response  from  the  Lth  PKG  is  valid  by  testing  that: 

HQ(;L,p)=i(Q:o,pi,ab) 

Thus,  a  misbehaving  PKG  will  be  immediately  caught.  There  is  no  need  for  zero-knowledge  proofs 
as  in  regular  robust  threshold  schemes  [21].  The  PKG’s  master-key  can  be  generated  in  a  distributed 
fashion  using  the  techniques  of  [22]. 

Note  that  a  distributed  master-key  also  enables  threshold  decryption  on  a  per-message  basis,  without 
any  need  to  derive  the  corresponding  decryption  key.  For  example,  threshold  decryption  of  Basicldent 
ciphertext  (U.  V )  is  straightforward  if  each  PKG  responds  with  e(siQ !D,  U ). 
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Working  in  subgroups.  The  performance  of  our  IBE  system  (Section  5)  can  be  improved  if  we  work 
in  a  small  subgroup  of  the  curve.  For  example,  choose  a  1024-bit  prime  p  =  2  mod  3  with  p  =  aq  —  1 
for  some  160-bit  prime  q.  The  point  P  is  then  chosen  to  be  a  point  of  order  q.  Each  public  key  ID  is 
converted  to  a  group  point  by  hashing  ID  to  a  point  Q  on  the  curve  and  then  multiplying  the  point 
by  a.  The  system  is  secure  if  the  BDH  assumption  holds  in  the  group  generated  by  P.  The  advantage 
is  that  the  Weil  computation  is  done  on  points  of  small  order,  and  hence  is  much  faster. 

IBE  implies  signatures.  Moni  Naor  has  observed  that  an  IBE  scheme  can  be  immediately  converted 
into  a  public  key  signature  scheme.  The  intuition  is  as  follows.  The  private  key  for  the  signature 
scheme  is  the  master  key  for  the  IBE  scheme.  The  public  key  for  the  signature  scheme  is  the  global 
system  parameters  for  the  IBE  scheme.  The  signature  on  a  message  M  is  the  IBE  decryption  key 
for  ID  =  M.  To  verify  a  signature,  choose  a  random  message  M',  encrypt  M'  using  the  public  key 
ID  =  M,  and  then  attempt  to  decrypt  using  the  given  signature  on  M  as  the  decryption  key.  If  the 
IBE  scheme  is  IND-ID-CCA,  then  the  signature  scheme  is  existentially  unforgeable  against  a  chosen 
message  attack.  Note  that,  unlike  most  signature  schemes,  the  signature  verification  algorithm  here  is 
randomized.  This  shows  that  secure  IBE  schemes  incorporate  both  public  key  encryption  and  digital 
signatures.  We  note  that  the  signature  scheme  derived  from  our  IBE  system  has  some  interesting 
properties  [6]. 


7  Escrow  ElGamal  encryption 

In  this  section  we  show  that  the  Weil  pairing  enables  us  to  add  a  global  escrow  capability  to  the 
ElGamal  encryption  system.  A  single  escrow  key  enables  the  decryption  of  ciphertexts  encrypted 
under  any  public  key.  Paillier  and  Yung  have  shown  how  to  add  a  global  escrow  capability  to  the 
Paillier  encryption  system  [36] .  Our  ElGamal  escrow  system  works  as  follows: 

Setup:  Let  Q  be  some  BDH  parameter  generator.  Given  a  security  parameter  k  G  Z+,  the  algorithm 
works  as  follows: 

Step  1:  Run  Q  on  input  k  to  generate  a  prime  q,  two  groups  Gi,G2  of  order  q.  and  an  admissible 
bilinear  map  e  :  Gi  x  Gi  — ►  G2.  Choose  a  random  generator  P  of  Gi. 

Step  2:  Pick  a  random  s  G  Z*  and  set  Q  =  sP. 

Step  3:  Choose  a  cryptographic  hash  function  H  :  G2  — >  {0,  l}n. 

The  message  space  is  M.  =  {0,  l}n.  The  ciphertext  space  is  C  =  Gi  x  {0,  l}n.  The  system  parameters 
are  params  =  (q,  Gi,  G2,  e,  n.  P,  Q,  H).  The  escrow  key  is  s  G  Z*. 

keygen:  A  user  generates  a  public/private  key  pair  for  herself  by  picking  a  random  x  G  Z*  and 
computing  Ppub  =  xP  G  Gi.  Her  private  key  is  x,  her  public  key  is  Ppub- 

Encrypt:  To  encrypt  M  G  {0,1}”  under  the  public  key  Ppub  do  the  following:  (1)  pick  a  random 
r  G  Z*,  and  (2)  set  the  ciphertext  to  be: 

C  =  ( rP ,  M  ©  H(gr ))  where  g  =  e(Ppub,  Q )  G  G2 

Decrypt:  Let  C  =  (U,V)  be  a  ciphertext  encrypted  using  Ppub-  Then  U  G  Gi.  To  decrypt  C  using 
the  private  key  x  do: 

V  ®  H(e(U,xQ))  =  M 

Escrow-decrypt:  To  decrypt  C  =  (U,  V)  using  the  escrow  key  s  do: 

V  ©  H(e(U,  sPpub))  =  M 
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A  standard  argument  shows  that  assuming  that  BDH  is  hard  for  groups  generated  by  Q  the  system 
has  semantic  security  in  the  random  oracle  model  (recall  that  since  DDH  is  easy  we  cannot  prove 
semantic  security  based  on  DDH).  Yet,  the  escrow  agent  can  decrypt  any  ciphertext  encrypted  using 
any  user’s  public  key.  The  decryption  capability  of  the  escrow  agent  can  be  distributed  using  the  PKG 
distribution  techniques  described  in  Section  6. 

Using  a  similar  hardness  assumption,  Verheul  [46]  described  an  ElGanral  encryption  system  with 
non-global  escrow.  Each  user  constructs  a  public  key  with  two  corresponding  private  keys,  and  gives 
one  of  the  private  keys  to  the  trusted  third  party.  The  trusted  third  party  must  maintain  a  database 
of  all  private  keys  given  to  it  by  the  various  users. 


8  Summary  and  open  problems 

We  defined  chosen  ciphertext  security  for  identity-based  systems  and  proposed  a  fully  functional  IBE 
system.  The  system  has  chosen  ciphertext  security  in  the  random  oracle  model  assuming  BDH,  a 
natural  analogue  of  the  computational  Diffie-Hellnran  problem.  The  BDH  assumption  deserves  further 
study  considering  the  powerful  cryptosystems  derived  from  it.  For  example,  it  could  be  interesting  to 
see  whether  the  techniques  of  [30]  can  be  used  to  prove  that  the  BDH  assumption  is  equivalent  to  the 
discrete  log  assumption  on  the  curve  for  certain  primes  p. 

Cocks  [8]  recently  proposed  another  IBE  system  whose  security  is  based  on  the  difficulty  of  distin¬ 
guishing  quadratic  residues  from  non-residues  in  the  ring  Z/1VZ  where  N  is  an  RSA  modulus  (i.e. ,  a 
product  of  two  large  primes).  Cocks’  system  is  somewhat  harder  to  use  in  practice  that  the  IBE  system 
in  this  paper.  Cocks’  system  uses  bit-by-bit  encryption  and  consequently  outputs  long  ciphertexts. 
Also,  encryption/decryption  is  a  bit  slower  than  the  system  described  in  this  paper.  Nevertheless,  it  is 
encouraging  to  see  that  IBE  systems  can  be  built  using  very  different  complexity  assumptions. 

It  is  an  open  problem  to  build  chosen  ciphertext  secure  identity  based  systems  that  are  secure  in 
the  standard  computation  model  (rather  than  the  random  oracle  model).  One  might  hope  to  use  the 
techniques  of  Cramer-Shoup  [10]  to  provide  chosen  ciphertext  security  based  on  DDH.  Unfortunately,  as 
mentioned  in  Section  3,  the  DDH  assumption  is  false  in  the  group  of  points  on  the  curve  E.  However, 
simple  variants  of  DDH  do  seem  to  hold.  In  particular,  the  following  two  distributions  appear  to 
be  computationally  indistinguishable:  (P,  aP ,  bP,  cP ,  abcP)  and  (P,  aP ,  bP,  cP ,  rP)  where  a,  b,  c,  r  are 
random  in  Zg.  We  refer  to  this  assumption  as  BDDH.  A  chosen  ciphertext  secure  identity-based  system 
strictly  based  on  BDDH  would  be  a  plausible  analogue  of  the  Cramer-Shoup  system.  Building  a  chosen 
ciphertext  secure  IBE  (IND-ID-CCA)  in  the  standard  model  is  currently  an  open  problem. 
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A  Definition  of  the  Weil  pairing 


We  define  the  Weil  pairing  and  show  how  to  efficiently  compute  it  using  an  algorithm  due  to  Miller  [34] . 
To  be  concrete  we  present  the  algorithm  as  it  applies  to  supersingular  elliptic  curves  defined  over  a 
prime  field  ¥p  with  p  >  3  (the  curve  y2  =  x3  +  1  over  IFP  with  p  =  2  mod  3  is  an  example  of  such  a 
curve).  The  definition  and  algorithm  easily  generalize  to  computing  the  Weil  pairing  over  other  elliptic 
curves.  We  state  a  few  elementary  facts  about  such  curves  [43]: 

Fact  1:  A  supersingular  curve  E/¥p  (with  p  >  3)  contains  p  +  1  points  in  IFP.  We  let  O  denote  the 
point  at  infinity.  The  group  of  points  over  IFP  forms  a  cyclic  group  of  order  p  +  1.  Let  P  G  E(¥p)  be 
a  point  order  n  where  n  divides  p  +  1. 

Fact  2:  The  group  of  points  E(¥p 2)  contains  a  point  Q  of  order  n  which  is  linearly  independent  of 
the  points  in  E(¥p).  Hence,  E(¥p 2)  contains  a  subgroup  which  is  isomorphic  to  the  group  1>2  .  The 
group  is  generated  by  P  G  E(IFp)  and  Q  G  E(¥p 2).  We  denote  this  group  by  E[n]. 

Throughout  this  section  we  let  G2  denote  the  subgroup  of  F*2  of  order  n.  We  will  be  working  with 
the  Weil  pairing  e  which  maps  pairs  of  points  in  E[n\  to  O2,  be.  e  :  E[n]  x  E[n ]  — >  O2.  To  define  the 
pairing,  we  review  a  few  basic  concepts  (see  [29,  pp.  243-245]).  In  what  follows  we  let  P  and  Q  be 
arbitrary  points  in  E(¥p 2). 

Divisors  A  divisor  is  a  formal  sum  of  points  on  the  curve  E(¥p 2).  We  write  divisors  as  A  =  Yp  ap(P) 
where  apG  Z  and  P  G  E(¥p 2).  For  example,  A  =  3(Pi)  —  2(^2)  —  (P3)  is  a  divisor.  We  will  only 
consider  divisors  A  =  Ypap(P)  where  Yip  ap  =  0- 

Functions  Roughly  speaking,  a  function  /  on  the  curve  E(¥p 2)  can  be  viewed  as  a  rational  function 
f(x,y )  G  ¥p2(x,y).  For  any  point  P  =  (x,y)  G  E(Fp2)  we  define  f(P)  =  f(x,y). 

Divisors  of  functions  Let  /  be  a  function  on  the  curve  E(¥p 2).  We  define  its  divisor,  denoted  by 
(/),  as  (/)  =  K)pordp(/)  •  ( P ).  Here  ord p(f)  is  the  order  of  the  zero  that  /  has  at  the  point 
P.  For  example,  let  ax  +  by  +  c  =  0  be  the  line  passing  through  the  points  P\ .  P2  G  E(¥p 2) 
with  P\  A  EP‘2-  This  line  intersects  the  curve  at  a  third  point  P3  G  E(¥p 2).  Then  the  function 
f(x ,  y)  =  ax  +  by  +  c  has  three  zeroes  Pi,  P-2,Pz  and  a  pole  of  order  3  at  infinity.  The  divisor  of 
/is  (/)  =  (Pi)  +  (P2)  +  (P3)-3(0). 

Principal  divisors  Let  A  be  a  divisor.  If  there  exists  a  function  /  such  that  (/)  =  A  then  we  say 
that  A  is  a  principal  divisor.  We  know  that  a  divisor  A  =  Yp  ap{P)  is  principal  if  and  only  if 
Yp  flp  =  0  and  YpaPp  =  O.  Note  that  the  second  summation  is  using  the  group  action  on  the 
curve.  Furthermore,  given  a  principal  divisor  A  there  exists  a  unique  function  /  (up  to  constant 
multiples)  such  that  (A)  =  (/). 

Equivalence  of  divisors  We  say  that  two  divisors  A,  B  are  equivalent  if  their  difference  A  —  B  is  a 
principal  divisor.  We  know  that  any  divisor  A  =  Ypap(P )  (with  YpaP  =  0)  is  equivalent  to  a 
divisor  of  the  form  A'  =  ( Q )  —  (O)  for  some  Q  G  E.  Observe  that  Q  =  YpapP- 

Notation  Given  a  function  /  and  a  divisor  A  =  Ypap{P )  we  define  /(A)  as  /(A)  =  Tip  f{P)ap  ■ 
Note  that  since  YpaP  =  0  we  have  that  /(A)  remains  unchanged  if  instead  of  /  we  use  cf  for 
any  c  G  Fp2 . 

We  are  now  ready  to  define  the  Weil  pairing  of  two  points  P,  Q  G  E[n\.  Let  Ap  be  some  divisor 
equivalent  to  the  divisor  ( P )  —  (O).  We  know  that  nAp  is  a  principal  divisor  (it  is  equivalent  to 
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n(P)  —  n(O)  which  is  clearly  a  principal  divisor).  Hence,  there  exists  a  function  fp  such  that  (fp)  = 
nAp.  Define  Aq  and  /q  analogously.  The  Weil  pairing  of  P  and  Q  is  defined  as: 


e(P,  Q ) 


fpjAq) 

/q(Ap) 


This  ratio  defines  the  Weil  pairing  of  P  and  Q  whenever  it  is  well  defined  (no  division  by  zero  occurred). 
If  this  ratio  is  undefined  we  use  different  divisors  Ap,Aq  to  define  e(P,  Q ). 

We  briefly  show  that  the  Weil  pairing  is  well  defined.  That  is,  the  value  of  e(P,  Q )  is  independent 
of  the  choice  of  the  divisor  Ap  as  long  as  yip  is  equivalent  to  (P)  —  (O)  and  Ap  leads  to  a  well  defined 
value.  The  same  holds  for  Aq.  Let  yip  be  a  divisor  equivalent  to  yip  and  let  fp  be  a  function  so  that 
(fp)  =  nAp.  Then  yip  =  yip  +  (g)  for  some  function  g  and  fp  =  fp  ■  gn.  We  have  that: 


,p  0]  =  [p(Aq)  =  fp(AQ)g(AQ)u  =  fp(AQ )  _  g(nAQ)  =  fp(AQ )  _  g((fQ))  =  fp(AQ) 

/g(ip)  /qMp)/q((s))  fQ(Ap)  fQ((g))  fQ(Ap)  fQ((g))  /q(^p) 

The  last  equality  follows  from  the  following  fact  known  as  Weil  reciprocity:  for  any  two  functions  /,  g 
we  have  that  /( (g) )  =  g(  (/) ).  Hence,  the  Weil  pairing  is  well  defined. 

Fact  A.l.  The  Weil  pairing  has  the  following  properties  for  points  in  E[n\ : 


•  For  all  P  £  E[n\  we  have:  e(P.  P)  =  1. 

•  Bilinear:  e(P\  +  P2,  Q)  =  e(P\,Q)  ■  e(P2,  Q)  and  e(P,  Qi  +  Q2 )  =  e(P,  Q\)  ■  e(P,  Q2 ). 

•  When  P,Q  £  E[n\  are  collinear  then  e(P,  Q)  =  1.  Similarly,  e(P,  Q)  =  e(Q,  P)~1 . 

•  n  ’th  root:  for  all  P,Q£  E[n]  we  have  e(P,  Q)n  =  1,  i.e.  e(P,  Q)  £  G2. 

•  Non- degenerate  in  the  following  sense:  if  P  £  E[n]  satisfies  e(P,  Q)  =  1  for  all  Q  £  E[n]  then 

p  =  o. 


As  discussed  in  Section  5,  our  concrete  IBE  scheme  uses  the  modified  Weil  pairing  e(P,  Q )  = 
e(P,  i i>(Q)),  where  <f  is  an  automorphism  on  the  group  of  points  of  E. 


Tate  pairing.  The  Tate  pairing  [17]  is  another  bilinear  pairing  that  has  the  required  properties  for 
our  system.  We  slightly  modify  the  original  definition  to  fit  our  purpose.  Define  the  Tate  pairing  of  two 
points  P,  Q  £  E[n]  as  T(P,Q)  =  fp(AQ^¥p2^n  where  fp  and  Aq  are  defined  as  above.  This  definition 
gives  a  computable  bilinear  pairing  T  :  E[n]  x  E[n\  — >  G2. 


B  Computing  the  Weil  pairing 

Given  two  points  P,Q  £  E[n\  we  show  how  to  compute  e(P,Q )  £  F*2  using  O(logp)  arithmetic 
operations  in  Fp.  We  assume  P  A  Q-  We  proceed  as  follows:  pick  two  random  points  R\,R2  £  E[n\. 
Consider  the  divisors  Ap  =  (P  +  R\)  —  (R\)  and  Aq  =  (Q  +  R2)  —  (R2).  These  divisors  are  equivalent 
to  (P)  —  (O)  and  (Q)  —  (O)  respectively.  Hence,  we  can  use  Ap  and  Aq  to  compute  the  Weil  pairing 
as: 

ip  r»  =  jHA?2  =  MQ  +  R2)fQ(Ri) 

e[  fQ(Ap)  fp(R2)fQ(P  +  Ri) 


201 


This  expression  is  well  defined  with  very  high  probability  over  the  choice  of  R\ ,  R2  (the  probability  of 
failure  is  at  most  O(^p))-  In  the  rare  event  that  a  division  by  zero  occurs  during  the  computation  of 
e(P,  Q )  we  simply  pick  new  random  points  Ri,  R2  and  repeat  the  process. 

To  evaluate  e(P,  Q )  it  suffices  to  show  how  to  evaluate  the  function  fp  at  Aq.  Evaluating  / q(Ap ) 
is  done  analogously.  We  evaluate  / p(Aq )  using  repeated  doubling.  For  a  positive  integer  b  define  the 
divisor 

Ab  =  b(P  +  i?i)  -  b(R1)  -  (bP)  P  (O) 

It  is  a  principal  divisor  and  therefore  there  exists  a  function  fb  such  that  (fb)  =  Ab-  Observe  that 
(fp)  =  ( fn )  and  hence,  / p(Aq )  =  fn(Aq).  It  suffices  to  show  how  to  evaluate  fn(AQ). 

Lemma  B.l.  There  is  an  algorithm  V  that  given  fb(Aq),  f c(Aq )  and  bP,  cP,  ( b+c)P  for  some  b,  c  >  0 
outputs  fb+c(AQ).  The  algorithm  only  uses  a  (small)  constant  number  of  arithmetic  operations  in  Wp2. 

Proof.  We  first  define  two  auxiliary  linear  functions  gi,g2- 

1.  Let  a\x  +  b\y  +  ci  =  0  be  the  line  passing  through  the  points  bP  and  cP  (if  b  =  c  then  let 
a\x  P  b\y  P  c\  =  0  be  the  line  tangent  to  E  at  bP).  Define  gi(x,  y)  =  a\x  P  b\y  P  ci. 

2.  Let  x  P  C2  =  0  be  the  vertical  line  passing  through  the  point  ( b  P  c)P.  Define  g2(x,  y)  =  x  P  C2 

The  divisors  of  these  functions  are: 

(gi)  =  (bP)  +  (cP)  +  (-(b  +  c)P)-3(0) 

C 92 )  =  ((b  +  c)P)  +  (— (6  +  c)P)  —  2(0) 

By  definition  we  have  that: 

Ab  =  b(P  +  RJ  -  b(Ri)  -  (bP)  +  (O) 

Ac  =  c(P  +  f?i)  —  c(f?i)  —  (cP)  +  (O) 

Ab+c  =  (bP  c)(P  +  R\)  —  (bp  c)(Ri)  —  ((b  P  c)P)  +  ( O ) 

It  now  follows  that:  Ab+C  =  Ab  P  Ac  P  (gi)  —  (gf)-  Hence: 

h+Ma)  =  MAq)  ■  IMq )  ■  fPf)  (2) 

This  shows  that  to  evaluate  fb+c(Aq)  it  suffices  to  evaluate  gi(AQ)  for  all  *  =  1,2  and  plug  the  results 

into  equation  2.  Hence,  given  fb(Aq),  fc(Aq)  and  bP,  cP ,  (b  P  c)P  one  can  compute  fb+c(Aq)  using  a 

constant  number  of  arithmetic  operations.  □ 

Let  V  (fb(Aq)  ■  fc(Aq),  bP,  cP ,  (bPc)P)  =  fb+c(Aq)  denote  the  output  of  Algorithm  V  of  Lemma  B.l 
above.  Then  one  can  compute  fp(Aq)  =  fn(Aq)  using  the  following  standard  repeated  doubling 
procedure.  Let  n  =  bmbm- 1 . . .  b\bo  be  the  binary  representation  of  n,  i.e.  n  = 

Init:  Set  Z  =  O,  V  =  fo(Aq)  =  1,  and  k  =  0. 

Iterate:  For  i  =  m,  m  —  1, . . . ,  1,  0  do: 

1:  If  bi  =  1  then  do:  Set  V  =  T>(V,  fi(Aq),  Z,  P,  Z  +  P),  set  Z  =  Z  P  P,  and  set  k  =  k  P  1. 

2:  If  i  >  0  set  V  =  T>(V,  V,  Z,  Z,  2 Z),  set  Z  =  2 Z,  and  set  k  =  2k. 


202 


3:  Observe  that  at  the  end  of  each  iteration  we  have  Z  =  kP  and  V  =  /fc(A<g). 

Output:  After  the  last  iteration  we  have  k  =  n  and  therefore  V  =  fn(AQ )  as  required. 

To  evaluate  the  Weil  pairing  e(P,  Q )  we  run  the  above  algorithm  once  to  compute  f p{Aq )  and  once  to 
compute  fcj(Ap).  The  Tate  pairing  is  evaluated  similarly.  Note  that  the  repeated  squaring  algorithm 
needs  to  evaluate  /i {Aq).  This  is  easily  done  since  the  function  fi(x,y)  (whose  divisor  is  (/i)  = 
(P  +  Ri)  —  ( R\ )  —  (P)  +  ( O )  )  can  be  written  out  explicitly  as  follows: 

1.  Let  ci\x  +  b\y  +  c±  =  0  be  the  line  passing  through  the  points  P  and  R\.  Define  the  function: 
gi(x,y)  =  aix  +  biy  +  ci. 

2.  Let  x  +  C2  =  0  be  the  vertical  line  passing  through  the  point  P  +  R±.  Define  the  function: 
92  (x,y)  =  x  +  c2. 

3.  The  function  f\(x,y)  is  simply  fi(x,y)  =  g2{x,y)/ gi(x,y)  which  is  easy  to  evaluate  in  ¥p2. 
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Abstract 

An  aggregate  signature  scheme  is  a  digital  signature  that  supports  aggregation:  Given  n 
signatures  on  n  distinct  messages  from  n  distinct  users,  it  is  possible  to  aggregate  all  these 
signatures  into  a  single  short  signature.  This  single  signature  (and  the  n  original  messages) 
will  convince  the  verifier  that  the  n  users  did  indeed  sign  the  n  original  messages  (i.e. ,  user  i 
signed  message  Mt  for  i  =  1, ...  ,ri).  In  this  paper  we  introduce  the  concept  of  an  aggregate 
signature,  present  security  models  for  such  signatures,  and  give  several  applications  for  aggregate 
signatures.  We  construct  an  efficient  aggregate  signature  from  a  recent  short  signature  scheme 
based  on  bilinear  maps  due  to  Boneh,  Lynn,  and  Shacham.  Aggregate  signatures  are  useful 
for  reducing  the  size  of  certificate  chains  (by  aggregating  all  signatures  in  the  chain)  and  for 
reducing  message  size  in  secure  routing  protocols  such  as  SBGP.  We  also  show  that  aggregate 
signatures  give  rise  to  verifiably  encrypted  signatures.  Such  signatures  enable  the  verifier  to  test 
that  a  given  ciphertext  C  is  the  encryption  of  a  signature  on  a  given  message  M.  Verifiably 
encrypted  signatures  are  used  in  contract-signing  protocols.  Finally,  we  show  that  similar  ideas 
can  be  used  to  extend  the  short  signature  scheme  to  give  simple  ring  signatures. 


1  Introduction 

Many  real-world  applications  involve  signatures  on  many  different  messages  generated  by  many 
different  users.  For  example,  in  a  Public  Key  Infrastructure  (PKI)  of  depth  n,  each  user  is  given 
a  chain  of  n  certificates.  The  chain  contains  n  signatures  by  n  Certificate  Authorities  (CAs)  on 
n  distinct  certificates.  Similarly,  in  the  Secure  BGP  protocol  (SBGP)  [18]  each  router  receives  a 
list  of  n  signatures  attesting  to  a  certain  path  of  length  n  in  the  network.  A  router  signs  its  own 
segment  in  the  path  and  forwards  the  resulting  list  of  n  +  1  signatures  to  the  next  router.  As 
a  result,  the  number  of  signatures  in  routing  messages  is  linear  in  the  length  of  the  path.  Both 
applications  would  benefit  from  a  method  for  compressing  the  list  of  signatures  on  distinct  messages 
issued  by  distinct  parties.  Specifically,  X.509  certificate  chains  could  be  shortened  by  compressing 
the  n  signatures  in  the  chain  into  a  single  signature. 

An  aggregate  signature  scheme  enables  us  to  achieve  precisely  this  type  of  compression.  Suppose 
each  of  n  users  has  a  public-private  key  pair  (PKj,  SKj).  User  m  signs  message  M;  to  obtain  a 
signature  oy.  Then  there  is  a  public  aggregation  algorithm  that  takes  as  input  all  of  cti,  . . . ,  an  and 
outputs  a  short  compressed  signature  a.  Anyone  can  aggregate  the  n  signatures.  Moreover,  the 
aggregation  can  be  performed  incrementally.  That  is,  signatures  <7i,<T2  can  be  aggregated  into  a  12 
which  can  then  be  further  aggregated  with  <73  to  obtain  <7123.  When  aggregating  signatures  in  a 
certificate  chain,  each  CA  can  incrementally  aggregate  its  own  signature  into  the  chain.  There  is 
also  an  aggregate  verification  algorithm  that  takes  PK 1, . . . ,  PKn,  Mi, . . . ,  Mn,  and  a  and  decides 
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whether  the  aggregate  signature  is  valid.  Intuitively,  the  security  requirement  is  that  the  aggregate 
signature  a  is  declared  valid  only  if  the  aggregator  who  created  a  was  given  all  of  ui, . . . ,  an.  Precise 
security  definitions  are  given  in  Sect.  3.2.  Thus,  an  aggregate  signature  provides  non-repudiation 
at  once  on  many  different  messages  by  many  users. 

We  construct  an  aggregate  signature  scheme  based  on  a  recent  short  signature  due  to  Boneh, 
Lynn,  and  Shacham  (BLS)  [6] .  This  signature  scheme  works  in  any  group  where  the  Decision  Diffie- 
Hellman  problem  (DDH)  is  easy,  but  the  Computational  Diffie-Hellman  problem  (CDH)  is  hard. 
We  refer  to  such  groups  as  gap  groups  [6,  26].  Recently  there  have  been  a  number  of  constructions 
using  such  gap  groups  [6,  19,  8,  4],  Surprisingly,  general  gap  groups  are  insufficient  for  constructing 
efficient  aggregate  signatures.  Instead,  our  construction  uses  a  pair  of  groups  G i,  Gt  and  a  bilinear 
map  e  :  G\  x  G\  — >  Gt  where  CDH  is  hard  in  G±.  Joux  and  Nguyen  [17]  showed  that  the  map  e 
can  be  used  to  solve  DDH  in  G\ ,  and  so  G\  is  a  gap  group.  It  is  the  extra  structure  provided  by 
the  bilinear  map  that  enables  us  to  construct  an  efficient  aggregate  signature  scheme.  We  do  not 
know  how  to  build  efficient  aggregate  signatures  from  general  gap  groups.  Thus,  our  construction 
is  an  example  where  the  bilinear  map  provides  extra  functionality  beyond  a  simple  algorithm  for 
solving  DDH.  Bilinear  maps  were  previously  used  for  three-way  Diffie-Hellman  [16] ,  Identity-Based 
Encryption  (IBE)  [5],  and  Hierarchical  IBE  [15,  13]. 

Aggregate  signatures  are  related  to  multisignatures  [20,  25,  24,  4],  In  multisignatures,  a  set  of 
users  all  sign  the  same  message  and  the  result  is  a  single  signature.  Recently,  Micali  et  al.  [20] 
defined  a  security  model  for  multisignatures  and  gave  some  constructions  and  applications.  Mul¬ 
tisignatures  are  insufficient  for  the  applications  we  have  in  mind,  such  as  certificate  chains  and 
SBGP.  For  these  applications  we  must  be  able  to  aggregate  signatures  on  distinct  messages.  We 
note  that  recently  Boldyreva  [4]  showed  that  general  gap  groups  are  sufficient  for  constructing  mul¬ 
tisignatures  from  BLS  signatures.  As  noted  above,  to  obtain  aggregate  signatures,  one  needs  the 
extra  structure  provided  by  bilinear  maps. 

Our  application  of  aggregate  signatures  to  compressing  certificate  chains  is  related  to  an  open 
problem  posed  by  Micali  and  Rivest  [21]:  Given  a  certificate  chain  and  some  special  additional 
signatures,  can  intermediate  links  in  the  chain  be  cut  out?  Aggregate  signatures  allow  the  com¬ 
pression  of  certificate  chains  without  any  additional  signatures,  but  a  verifier  must  still  be  aware 
of  all  intermediate  links  in  the  chain.  We  note  that  batch  RSA  [9]  also  provides  some  signature 
compression,  but  only  for  signatures  produced  by  a  single  signer. 

As  a  further  application  for  aggregate  signatures  we  show  in  Sect.  4  that  certain  aggregate 
signature  schemes  give  rise  to  simple  verifiably  encrypted  signatures.  These  signatures  enable  user 
Alice  to  give  Bob  a  signature  on  a  message  M  encrypted  using  a  third  party’s  public  key  and  Bob  to 
verify  that  the  encrypted  signature  is  valid.  Verifiably  encrypted  signatures  are  used  in  optimistic 
contract  signing  protocols  [1,  2]  to  enable  fair  exchange.  Previous  constructions  [1,  27]  require  zero 
knowledge  proofs  to  verify  an  encrypted  signature.  The  verifiably  encrypted  signatures  in  Section  4 
are  short  and  can  be  validated  efficiently.  We  note  that  the  resulting  contract  signing  protocol  is 
not  abuse- free  in  the  sense  of  [10]. 

As  a  third  application  of  these  ideas  we  construct  in  Sect.  5  a  simple  ring  signature  [28]  using 
bilinear  maps.  As  above,  the  construction  using  a  bilinear  map  is  simpler  and  more  efficient  than 
constructions  that  only  make  use  of  gap  groups. 

2  Signature  Schemes  Based  on  Co-Gap  Diffie-Hellman 

We  first  review  a  few  concepts  related  to  bilinear  maps  and  Gap  Diffie-Hellman  signatures  [6]. 
Throughout  the  paper  we  use  the  following  notation: 
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1 .  G i  and  G2  are  two  (multiplicative)  cyclic  groups  of  prime  order  p\ 

2.  g\  is  a  generator  of  G\  and  52  is  a  generator  of  G2 ; 

3.  ip  is  a  computable  isomorphism  from  G2  to  Gi,  with  ip(g2)  =  51;  and 

4.  e  is  a  computable  bilinear  map  e  :  G\  x  G2  —>  Gt  as  described  below. 

The  isomorphism  ip  is  mostly  needed  for  the  proofs  of  security.  To  keep  the  discussion  general,  we 
simply  assume  that  ip  exists  and  is  efficiently  computable.  When  G 1,  G2  are  subgroups  of  the  group 
of  points  of  an  elliptic  curve  E/¥q,  the  trace  map  on  the  curve  can  be  used  as  this  isomorphism 
(we  assume  G\  C  E(¥q)  and  G2  C  E(¥qr)). 

Throughout  the  paper,  we  consider  bilinear  maps  e  :  G\  x  G2  —■ ►  Gt  where  all  groups  G\,  G2,  Gt 
are  multiplicative  and  of  prime  order  p.  One  could  set  G 1  =  G2.  However,  we  allow  for  the  more 
general  case  where  G\  A  G2  so  that  our  constructions  can  make  use  of  certain  families  of  non¬ 
supersingular  elliptic  curves  defined  by  Miyaji  et  al.  [22].  These  curves  give  rise  to  very  short 
signatures  [6].  This  will  lead  in  turn  to  short  aggregate  signatures,  ring  signatures,  etc.  To  handle 
the  case  G\  A  G2  we  define  the  co-CDH  and  co-DDH  problems  [6].  When  G\  =  G2,  these  problems 
reduce  to  the  standard  CDH  and  DDH  problems.  Hence,  for  the  remainder  of  the  paper,  although 
we  handle  arbitrary  G±,G2,  for  simplicity,  the  reader  may  assume  G\  =  G2,gi  =  <72,  and  ip  =  I, 
the  identity  map. 

With  this  setup  we  obtain  natural  generalizations  of  the  CDH  and  DDH  problems: 


Computational  Co-Diffie-Hellman.  Given  g2,g%  £  G2  and  h  £  G\  compute  ha  £  Gi. 

Decision  Co-Diffie-Hellman.  Given  g2,  £  G2  and  h,hb  £  G\  output  yes  if  a  =  b  and  no 

otherwise.  When  the  answer  is  yes  we  say  that  (g2,  g%,  h,  ha )  is  a  co-Difhe-Hellnran  tuple. 

When  G\  =  G2  and  g \  =  g2 ,  these  problems  reduce  to  the  standard  CDH  and  DDH.  Next  we  define 
co-GDH  gap  groups  to  be  group  pairs  G\  and  G 2  on  which  co-DDH  is  easy  but  co-CDH  is  hard. 

Definition  2.1.  Two  groups  {G\,G2j  are  a  decision  group  pair  for  co-Diffie-Hellman  if  the  group 
action  on  G\ ,  the  group  action  on  G2,  and  the  map  ip  from  G2  to  G\  can  be  computed  in  one  time 
unit,  and  Decision  co-Diffie-Hellman  on  (Gi,Cr2)  can  be  solved  in  one  time  unit. 

Definition  2.2.  The  advantage  of  an  algorithm  A  in  solving  the  Computational  co-Diffie-Hellman 
problem  in  groups  G\  and  G2  is 


Adv  co-CDH_4  =f  Pr  | -4. ( <72 ,  ^2 5  h)  =  ha 


R 


R 


Zp,  h  A-  G 1 


The  probability  is  taken  over  the  choice  of  a,  h,  and  yi’s  coin  tosses.  An  algorithm  A  (t,  e)-breaks 
Computational  co-Diffie-Hellman  on  Gi  and  G2  if  A  runs  in  time  at  most  t,  and  Adv  co-CDH_4  is 
at  least  e.  Two  Groups  (Gi,G2)  are  a  (t,e)-co-GDH  group  pair  if  they  are  a  decision  group  pair 
for  co-Diffie-Hellman  and  no  algorithm  (i,  e)-breaks  Computational  co-Diffie-Hellman  on  them. 


2.1  Bilinear  Maps 

Let  Gi  and  G 2  be  two  groups  as  above,  with  an  additional  group  Gt  such  that  |Gi|  =  |  G2 1  =  |Gt|- 
A  bilinear  map  is  a  map  e  :  G±  x  G2  — ; >  Gt  with  the  following  properties: 

1.  Bilinear:  for  all  u  £  G\,v  £  G2  and  a,  6  £  Z,  e(ua,vb)  =  e(u,v)ab. 
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2.  Non-degenerate:  e(gi,g2)  /  1. 

These  properties  imply  two  more:  for  any  U\,U2  £  G i,v  £  G 2,  e(u\ii2,v)  =  e(u\,v)  ■  e(u2,v)',  and 
for  any  u,  v  £  G2,  e(i/>(u),v)  =  e{if{v),u). 

Definition  2.3.  Two  groups  (G 1,  G2)  are  a  bilinear  group  pair  if  the  group  action  on  either  can  be 
computed  in  one  time  unit,  the  map  if  from  G2  to  G\  can  be  computed  in  one  time  unit,  a  bilinear 
map  e  :  Gj  x  G2  -»  Gt  exists,  and  e  is  computable  in  one  time  unit. 

Definition  2.4.  Two  groups  ( G\,G2 )  are  a  (t,  e)-bilinear  group  pair  for  co-Diffie-Hellman  if  they 
are  a  bilinear  group  pair  and  no  algorithm  (t,  e)-breaks  Computational  co-Diffie-Hellman  on  them. 

Joux  and  Nguyen  [17]  showed  that  an  efficiently-computable  bilinear  map  e  provides  an  algo¬ 
rithm  for  solving  the  decision  co-Diffie-Hellman  problem.  For  a  tuple  (g2,  #2 ,  h,  hb )  we  have 

a  =  b  mod  p  e(h,  g%)  =  e(hb,  g2)  . 

Consequently,  if  two  groups  (Gi,  G2)  are  a  (t,  e)-bilinear  group  pair  for  co-Diffie-Hellman,  then  they 
are  also  a  (i/2,  e)-co-GDH  group  pair.  The  converse  is  probably  not  true. 

2.2  The  Co-GDH  Signature  Scheme 

We  review  the  signature  scheme  of  [6],  which  can  be  based  on  any  gap  group.  It  comprises  three 
algorithms,  KeyGen,  Sign,  and  Verify,  and  uses  a  full-domain  hash  function  H  :  {0,1}*  — ►  G\, 
viewed  as  a  random  oracle  [3] . 

Ft 

Key  Generation.  Pick  random  x  <—  Zp,  and  compute  v  4—  g%.  The  public  key  is  v  £  G 2.  The 
secret  key  is  x  £  Zp. 

Signing.  Given  a  secret  key  x  and  a  message  M  £  {0, 1}*,  compute  h  4—  H(M),  where  h  £  G\, 
and  a  <—  hx.  The  signature  is  a  £  G\. 

Verification.  Given  a  public  key  v,  a  message  M,  and  a  signature  u,  compute  h  <—  H(M )  and 
verify  that  (52,  v,  h,  a)  is  a  valid  co-Diffie-Hellman  tuple. 

A  co-GDH  signature  is  a  single  element  of  G\.  On  certain  elliptic  curves  these  signatures  are  very 
short:  they  are  half  the  size  of  DSA  signatures  with  similar  security.  Theorem  1  of  [6]  proves  the 
existential  unforgeability  of  the  scheme  under  a  chosen  message  attack  [14]  in  the  random  oracle 
model  assuming  (G\,G2)  is  a  co-gap  group  pair  for  Diffie-Hellman. 

3  Aggregate  Signatures 

We  define  aggregate  signatures  and  describe  an  aggregate  signature  scheme  based  on  co-GDH 
signatures.  Unlike  the  co-GDH  scheme,  aggregate  signatures  require  the  existence  of  a  bilinear 
map.  We  define  security  models  and  provide  proofs  of  security  for  aggregate  signatures. 

Consider  a  set  U  of  users.  Each  user  u  £  U  has  a  signing  keypair  (PKU,  SKU).  We  wish  to 
aggregate  the  signatures  of  some  subset  PC  U.  Each  user  u  £  U  produces  a  signature  au  on  a 
message  Mu  of  her  choice.  These  signatures  are  then  combined  into  a  single  aggregate  a  by  an 
aggregating  party.  The  aggregating  party,  who  can  be  different  from  and  untrusted  by  the  users 
in  U,  has  access  to  the  users’  public  keys,  to  the  messages,  and  to  the  signatures  on  them,  but  not 
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to  any  private  keys.  The  result  of  this  aggregation  is  an  aggregate  signature  a  whose  length  is  the 
same  as  that  of  any  of  the  individual  signatures.  This  aggregate  has  the  property  that  a  verifier 
given  <7  along  with  the  identities  of  the  parties  involved  and  their  respective  messages  is  convinced 
that  each  user  signed  her  respective  message. 


3.1  Bilinear  Aggregate  Signatures 

We  describe  a  bilinear  aggregate  signature  scheme  based  on  the  co-GDH  scheme  presented  above. 
Individual  signatures  in  the  aggregate  signature  scheme  are  created  and  verified  precisely  as  are 
signatures  in  the  co-GDH  scheme  (Sect.  2.2).  Aggregate  verification  makes  use  of  a  bilinear  map 
on  G\  and  G-2- 

The  aggregate  signature  scheme  allows  the  creation  of  signatures  on  arbitrary  distinct  messages 
Mi  G  {0, 1}*.  An  individual  signature  a,;  is  an  element  of  G\.  The  base  groups  G\  and  G 2,  their 
respective  generators  g±  and  g2 ,  the  computable  isomorphism  if  from  G 2  to  G 1,  and  the  bilinear 
map  e  :  Gj  x  G2  -»  Gt,  with  target  group  Gt,  are  system  parameters. 

The  scheme  comprises  five  algorithms:  Key  Gen,  Sign,  Verify,  Aggregate,  and  Aggregate  Verify. 
The  first  three  are  as  in  ordinary  signature  schemes;  the  last  two  provide  the  aggregation  capability. 
The  scheme  employs  a  full-domain  hash  function  H  :  {0, 1}*  — >  G\,  viewed  as  a  random  oracle. 

R, 

Key  Generation.  For  a  particular  user,  pick  random  x  <—  Zp,  and  compute  v  <—  gif  ■  The  user’s 
public  key  is  v  G  G2-  The  user’s  secret  key  is  x  G  Zp. 

Signing.  For  a  particular  user,  given  the  secret  key  x  and  a  message  M  G  {0, 1}*,  compute 

h  <—  H(M),  where  h  G  G\,  and  a  «—  hx .  The  signature  is  c  G  Gi. 

Verification.  Given  user’s  public  key  v,  a  message  M,  and  a  signature  a,  compute  h  <—  H(M ); 
accept  if  e(a,  52)  =  e(h,v)  holds. 

Aggregation.  For  the  aggregating  subset  of  users  1/CU,  assign  to  each  user  an  index  i,  ranging 
from  1  to  k  =  \U\.  Each  user  Ui  G  U  provides  a  signature  crl  G  G\  on  a  message  Mi  G  {0, 1}* 
of  his  choice.  The  messages  Mt  must  all  be  distinct.  Compute  a  <—  nf=i  ai ■  The  aggregate 
signature  is  a  G  Gi. 

Aggregate  Verification.  We  are  given  an  aggregate  signature  a  G  G\  for  an  aggregating  subset 
of  users  U ,  indexed  as  before,  and  are  given  the  original  messages  M t  G  {0, 1}*  and  public 
keys  Vi  G  G 2  for  all  users  Ui  G  U.  To  verify  the  aggregate  signature  a, 

1.  ensure  that  the  messages  Mi  are  all  distinct,  and  reject  otherwise;  and 

2.  compute  ht  <—  H(Mf)  for  1  <  i  <  k  =  \U\,  and  accept  if  e(a,  <72)  =  n!=i  e{hi,  vt)  holds. 

A  bilinear  aggregate  signature,  like  a  co-GDH  signature,  is  a  single  element  of  G\.  Note  that 
aggregation  can  be  done  incrementally. 

The  intuition  behind  bilinear  aggregate  signatures  is  as  follows.  Each  user  ut  has  a  secret 
key  Xi  G  Zp  and  a  public  key  Vi  =  gf‘ .  User  uf  s  signature,  if  correctly  formed,  is  at  =  hf% ,  where  ht 
is  the  hash  of  the  user’s  chosen  message,  Mt .  The  aggregate  signature  a  is  thus  a  =  FI,  ai  =  Re¬ 
using  the  properties  of  the  bilinear  map,  the  left-hand  side  of  the  verification  equation  expands: 


e(v,g2)  =  e(Y[.h*i,g2)  =  JJ.  e(hi,  g2)Xi  =  JJ.  e(/i*,  gff)  =  J]\  e(/i,:,  v,)  , 
which  is  the  right-hand  side,  as  required.  It  remains  to  prove  the  security  of  the  scheme. 
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3.2  Aggregate  Signature  Security 

Informally,  the  security  of  aggregate  signature  schemes  is  equivalent  to  the  nonexistence  of  an  adver¬ 
sary  capable,  within  the  confines  of  a  certain  game,  of  existentially  forging  an  aggregate  signature. 
Existential  forgery  here  means  that  the  adversary  attempts  to  forge  an  aggregate  signature,  on 
messages  of  his  choice,  by  some  set  of  users. 

We  formalize  this  intuition  as  the  aggregate  chosen-key  security  model.  In  this  model,  the 
adversary  A  is  given  a  single  public  key.  His  goal  is  the  existential  forgery  of  an  aggregate  signature. 
We  give  the  adversary  power  to  choose  all  public  keys  except  the  challenge  public  key.  The  adversary 
is  also  given  access  to  a  signing  oracle  on  the  challenge  key.  His  advantage,  Adv  AggSig^,  is  defined 
to  be  his  probability  of  success  in  the  following  game. 

Setup.  The  aggregate  forger  A  is  provided  with  a  public  key  PK\ ,  generated  at  random. 
Queries.  Proceeding  adaptively,  A  requests  signatures  with  PK\  on  messages  of  his  choice. 

Response.  Finally,  A  outputs  k  —  1  additional  public  keys  PK2, . . . ,  PK^.  Here  k  is  at 
most  A,  a  game  parameter.  These  keys,  along  with  the  initial  key  PK\ .  will  be  included 
in  A’s  forged  aggregate.  A  also  outputs  messages  M\, . . . ,  M ^ ;  and,  finally,  an  aggregate 
signature  a  by  the  k  users,  each  on  his  corresponding  message. 

The  forger  wins  if  the  aggregate  signature  a  is  a  valid  aggregate  on  messages  M i, . . . ,  M ^ 
under  keys  PKi, . . . ,  PK^,  and  a  is  nontrivial,  i.e.,  A  did  not  request  a  signature  on  M\ 
under  PK\ .  The  probability  is  over  the  coin  tosses  of  the  key-generation  algorithm  and  of  A. 

Definition  3.1.  An  aggregate  forger  A  (t,  qH,  qs ,  A,  e)-breaks  an  A-user  aggregate  signature  scheme 
in  the  aggregate  chosen-key  model  if:  A  runs  in  time  at  most  t ;  A  makes  at  most  qH  queries  to  the 
hash  function  and  at  most  qs  queries  to  the  signing  oracle;  Adv  AggSig_4  is  at  least  e;  and  the  forged 
aggregate  signature  is  by  at  most  A  users.  An  aggregate  signature  scheme  is  ( t ,  qH,qsi  A,  e)-secure 
against  existential  forgery  in  the  aggregate  chosen-key  model  if  no  forger  (t,qH,qs,  A,  e)-breaks  it. 

A  potential  attack  on  aggregate  signatures.  The  adversary’s  ability  in  the  chosen-key  model 
to  generate  keys  suggests  the  following  attack,  previously  considered  in  the  context  of  multisigna¬ 
tures  [20,  4],  Alice  publishes  her  public  key  v  a-  Bob  generates  a  private  key  x'B  and  a  public 

key  v'B  =  g2B ,  but  publishes  as  his  public  key  vb  =  v'B/v a,  a  value  whose  discrete  log  he  does  not 
know.  Then  H(M)xb  verifies  as  an  aggregate  signature  on  M  by  both  Alice  and  Bob.  Note  that 
in  this  forgery  Alice  and  Bob  both  sign  the  same  message  M. 

One  countermeasure  is  to  require  the  adversary  to  prove  knowledge  of  the  discrete  logarithms 
(to  base  52)  of  his  published  public  keys.  For  example,  Boldyreva,  in  her  multisignature  scheme  [4], 
requires,  in  effect,  that  the  adversary  disclose  the  corresponding  private  keys  X2 ,  •  •  •  ,Xk ■  Micali  et 
al.  [20]  discuss  a  series  of  more  sophisticated  approaches  based  on  zero-knowledge  proofs,  again  with 
the  effect  that  the  adversary  is  constrained  in  his  key  selection.  These  defenses  apply  equally  well 
to  our  aggregate  signature  scheme.  For  aggregate  signatures,  though,  there  is  a  simpler  defense. 

A  simple  defense  for  aggregate  signatures.  In  the  context  of  aggregate  signatures  we  can 
defend  against  the  attack  above  by  simply  requiring  that  an  aggregate  signature  is  valid  only  if 
it  is  an  aggregation  of  signatures  on  distinct  messages.  This  restriction,  codified  in  Step  1  of 
AggregateVerify,  suffices  to  prove  the  security  of  the  bilinear  aggregate  signature  scheme  in  the 
chosen-key  model.  There  is  no  need  for  zero-knowledge  proofs  or  the  disclosure  of  private  keys. 
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The  requirement  that  all  messages  in  an  aggregate  be  distinct  is  naturally  satisfied  for  the 
applications  to  certificate  chains  and  SBGP  we  have  in  mind.  Even  in  more  general  environments 
it  is  easy  to  ensure  that  all  messages  are  distinct:  The  signer  simply  prepends  her  public  key  to 
every  message  she  signs  prior  to  the  application  of  the  hash  function  H.  The  implicit  prefix  need 
not  be  transmitted  with  the  signature,  so  signature  and  message  length  is  unaffected. 

The  next  theorem  shows  that  this  simple  constraint  is  sufficient  for  proving  security  in  the 
chosen-key  model. 

Theorem  3.2.  Let  (G\,G2)  be  a  (t1 2 ,  e') -bilinear  group  pair  for  co-Diffie-Hellman,  with  each  group 
of  order  p,  with  respective  generators  g\  and  <72  >  with  an  isomorphism  if  computable  from  G2  to  G\, 
and  with  a  bilinear  map  e  :  Gi  x  G2  — >  Gt-  Then  the  bilinear  aggregate  signature  scheme  on 
(Gi,G2)  is  (t,  qH,  qs,  N,  e)-secure  against  existential  forgery  in  the  aggregate  chosen-key  model  for 
all  t  and  e  satisfying 

e  >  e(qs  +  N)  ■  e'  and  t  <  t!  -  cGl  (qH  +  2qs  +  N  +  4)  -  (N  +  1)  , 

where  e  is  the  base  of  natural  logarithms,  and  exponentiation  and  inversion  on  G\  take  time  cGl . 

Proof.  Suppose  A  is  a  forger  algorithm  that  (t,  qs,QH,  N,  e)-breaks  the  signature  scheme.  We  show 
how  to  construct  a  P-tirne  algorithm  C  that  solves  co-CDH  in  [G 1,  G2)  with  probability  at  least  e' . 
This  will  contradict  the  fact  that  (G 1,  G2)  are  a  (t1 ,  e/)-co-GDH  group  pair. 

Let  g2  be  a  generator  of  G2.  Algorithm  C  is  given  <72 >  u  £  G2  and  h  £  Gi,  where  u  =  gf.  Its  goal 
is  to  output  ha  gG  1.  Algorithm  C  simulates  the  challenger  and  interacts  with  forger  A  as  follows. 

Setup.  Algorithm  C  starts  by  giving  A  the  generator  52  and  the  public  key  v\  =  u-  g%  £  G2,  where 
r  is  random  in  Zp. 

Hash  Queries.  At  any  time  algorithm  A  can  query  the  random  oracle  H.  To  respond  to  these 
queries,  C  maintains  a  list  of  tuples  (M^\w^\b^\c^)  as  explained  below.  We  refer  to 
this  list  as  the  H- list.  The  list  is  initially  empty.  When  A  queries  the  oracle  H  at  a  point 
M  £  {0, 1}*,  algorithm  C  responds  as  follows: 

1.  If  the  query  M  already  appears  on  the  H- list  in  some  tuple  (M,  w,  b,  c)  then  algorithm  C 
responds  with  H(M)  =  w  £  G\. 

2.  Otherwise,  C  generates  a  random  coin  c  £  {0, 1}  so  that  Pr[c  =  0]  =  l/(qs  +  AT). 

3.  Algorithm  C  picks  a  random  b  £  Zp.  If  c  =  0  holds,  C  computes  w  <—  h-  ip(g2)b  €  G\.  If 
c  =  1  holds,  C  computes  w  <—  if(g2)b  £  G\ . 

4.  Algorithm  C  adds  the  tuple  (M,  w,  b,  c)  to  the  H- list  and  responds  to  A  as  H(M)  =  w. 

Note  that,  either  way,  w  is  uniform  in  G±  and  is  independent  of  A’s  current  view  as  required. 

Signature  queries.  Algorithm  A  requests  a  signature  on  some  message  M  under  the  challenge 
key  V] .  Algorithm  C  responds  to  this  query  as  follows: 

1.  Algorithm  C  runs  the  above  algorithm  for  responding  to  H- queries  on  M ,  obtaining  the 
corresponding  tuple  ( M,w,b,c }  on  the  IL-list.  If  c  =  0  holds  then  C  reports  failure  and 
terminates. 

2.  We  know  that  c  =  1  holds  and  hence  w  =  if(g2)b  £  G\.  Let  a  =  if(u)b  ■  if{g2)rb  £  G\. 
Observe  that  a  =  wa+r  and  therefore  a  is  a  valid  signature  on  M  under  the  public  key 
v\  =  u  ■  ^2  =  <72 +r-  Algorithm  C  gives  a  to  algorithm  A. 
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Output.  Finally,  A  halts.  It  either  concedes  failure,  in  which  case  so  does  C,  or  it  returns  a 
value  k  (where  k  <  N),  k  —  1  public  keys  u2 ,  ■  •  ■ ,  vy.  £  G2,  k  messages  M\, . . .  M^,  and  a 
forged  aggregate  signature  a  £  G\.  The  messages  M,  must  all  be  distinct,  and  A  must  not 
have  requested  a  signature  on  M \ .  Algorithm  C  runs  its  hash  algorithm  at  each  Mj,  1  <  i  <  k, 
obtaining  the  k  corresponding  tuples  (Mj,  Wi,  bi,  cf)  on  the  iL-list. 

Algorithm  C  now  proceeds  only  if  c\  =  0  and,  for  2  <  i  <  k,  Ci  =  1;  otherwise  C  declares 
failure  and  halts.  Since  c\  =  0,  it  follows  that  w\  =  h  ■  ip(g2)bl-  For  i  >  1,  since  ct  =  1,  it 
follows  that  Wi  =  ijj(g2)bi-  The  aggregate  signature  a  must  satisfy  the  aggregate  verification 
equation,  e(cr,  g2)  =  n!=i  e(wi,Vi).  For  each  i  >  1,  C  sets  crj  <—  if(yi)bi-  Then,  for  i  >  1, 

e(cr  i,g2)  =  e^(vi)bi ,  g2)  =  e(if(vi) ,  g2)bi  =  ,  Vi)bi  =  e(ip(g2)bi  ,Vi)  =  e{wilvi)  , 

So  a i  is  a  valid  signature  on  Mj  (whose  hash  is  Wi)  by  the  key  whose  public  component  is  Uj. 
Now  C  constructs  a  value  a\:  o\  <—  a  ■  (n-  =2  <Tj)  .  Then 

k  k 

e(<J1,g2)  =  e(a,g2)  ■  e(c7j,  52)_1  =  JJe(wj,Uj)  •  e(wi,  u*)'1  =  e(rci,t>i)  . 

«=2  i=l  i=2 

Thus  1  is  a  valid  co-GDH  signature  by  key  v\  =  u-g^  =  g^+r  on  a  message  whose  hash  is  w\  = 
h-'ip(g2)bl ■  Then  C  calculates  and  outputs  the  required  ha  as  ha  <—  ai-(^(u)bl  •  hr  ■'ip(g2)rbl)~1  ■ 

This  completes  the  description  of  algorithm  C.  It  remains  to  show  that  C  solves  the  given  instance 
of  the  co-CDH  problem  in  (Gi,^)  with  probability  at  least  e' .  To  do  so,  we  analyze  the  three 
events  needed  for  C  to  succeed: 

£\ :  C  does  not  abort  as  a  result  of  any  of  A’s  signature  queries. 

£ 2 •  A  generates  a  valid  and  nontrivial  aggregate  signature  forgery  ( k ,  V2,  ■  ■  ■ ,  Vk,  Mi, . . . ,  M&,  a). 

£3:  Event  £2  occurs,  and,  in  addition,  ci  =  0,  and,  for  2  <  i  <  k,  Ci  =  1,  where  for  each  i  Ci  is  the 
c-component  of  the  tuple  containing  Mj  on  the  H- list. 

C  succeeds  if  all  of  these  events  happen.  The  probability  Pr[<?i  A  £3]  decomposes  as 

Pr[£r  A  £3]  =  Pr[£i]  •  Pr[£2  |  £1]  •  Pr[£3  |  £1  A  £2] .  (1) 

The  following  claims  give  a  lower  bound  for  each  of  these  terms. 

Claim  3.3.  The  probability  that  algorithm  C  does  not  abort  as  a  result  of  A’s  aggregate  signature 
queries  is  at  least  (1  —  l/(qs  +  N))qs .  Hence,  Pr[£i]  >  (1  —  l/(gs  +  N))qs . 

Proof.  Without  loss  of  generality  we  assume  that  A  does  not  ask  for  the  signature  of  the  same 
message  twice.  We  prove  by  induction  that  after  A  makes  t  signature  queries  the  probability 
that  C  does  not  abort  is  at  least  (1  —  1/(^5  +  N)Y .  The  claim  is  trivially  true  for  l  =  0.  Let 
be  A’s  £th  signature  query  and  let  (M^\w^\b^\c^)  be  the  corresponding  tuple  on  the  H- list. 
Then,  prior  to  A’s  issuing  the  query,  the  bit  is  independent  of  A’s  view  —  the  only  value  that 
could  be  given  to  A  that  depends  on  is  M(M^),  but  the  distribution  of  H(M^)  is  the  same 
whether  cM'1  =  0  or  c ^  =  1.  Therefore,  the  probability  that  this  query  causes  C  to  abort  is  at  most 
1  /(qs  +  N ).  Using  the  inductive  hypothesis  and  the  independence  of  c^\  the  probability  that  C 
does  not  abort  after  this  query  is  at  least  (1  —  1  /(qs  +  N)Y .  This  proves  the  inductive  claim. 
Since  A  makes  at  most  qs  signature  queries  the  probability  that  C  does  not  abort  as  a  result  of  all 
signature  queries  is  at  least  (1  —  l/(qs  +  N))qs .  □ 
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Claim  3.4.  If  algorithm  C  does  not  abort  as  a  result  of  A’s  queries  then  algorithm  A’s  view  is 
identical  to  its  view  in  the  real  attack.  Hence,  Pr[<?2  |  £1]  >  e. 

Proof.  The  public  key  given  to  A  is  from  the  same  distribution  as  public  keys  produced  by  algo¬ 
rithm  KeyGen.  Responses  to  hash  queries  are  as  in  the  real  attack  since  each  response  is  uniformly 
and  independently  distributed  in  G\ .  Since  C  did  not  abort  as  a  result  of  A’s  signature  queries,  all 
its  responses  to  those  queries  are  valid.  Therefore  A  will  produce  a  valid  and  nontrivial  aggregate 
signature  forgery  with  probability  at  least  e.  Hence  Pr[£2  |  £1]  >  e.  □ 

Claim  3.5.  The  probability  that  algorithm  C  does  not  abort  after  A  outputs  a  valid  and  nontrivial 
forgery  is  at  least  (1  —  l/(qs  +  iV))^-1  ■  l/(qs  +  N). 

Hence,  Pr[£3  \  £x  A  £2]  >  (1  -  l/(qs  +  N))^1  •  l/(qs  +  N). 

Proof.  Events  £\  and  £2  have  occurred,  and  A  has  generated  some  valid  and  nontrivial  forgery 
( k ,  v2,  ■  ■  ■ ,  Vk,  Mi, . . . ,  Mfc,  a).  For  each  i,  1  <  i  <  k,  let  (Mt,  Wi,  bi,cf)  be  the  tuple  corresponding 
to  Mi  on  the  H-list.  Algorithm  C  will  abort  unless  A  generates  a  forgery  such  that  ci  =  0  and,  for 
i  >  1,  Cj  =  1. 

Since  all  the  messages  Mi,  M2, . . . ,  M&  are  distinct,  the  values  ci,  C2, . . . ,  are  all  independent 
of  each  other;  as  before,  H{Mj)  =  Wi  is  independent  of  Cj  for  each  i. 

Since  its  forgery  is  nontrivial,  A  cannot  have  asked  for  a  signature  on  Mi  under  key  v\.  It 
can  thus  have  no  information  about  the  value  of  ci ;  in  the  forged  aggregate,  ci  =  0  occurs  with 
probability  1  /{qs  +  N ).  For  each  i  >  1,  A  either  asked  for  a  signature  under  key  v\  on  Mi,  in  which 
case  Ci  =  1  with  probability  1,  or  it  didn’t,  and  q  =  1  with  probability  1  —  1  /(qs  +  N).  Regardless, 
the  probability  that  c,  =  1  for  alii,  2  <  i  <  k,  is  at  least  (1  —  1  /(qs  +  ./V))*’-1  >  (1  —  1  /(qs  +  N ))N~1. 
Therefore  Pr[£3  |  £\  A  £2]  >  (1  —  l/(<?s  +  N))N~l  ■  1  /{qs  +  IV),  as  required.  □ 

To  complete  the  proof  of  Theorem  3.2,  we  use  the  bounds  from  the  claims  above  in  equation  (1). 
Algorithm  C  produces  the  correct  answer  with  probability  at  least 

1  ys+N-\  J  e/e 

qs  +  N  J  qs  +  N  qs  +  N 

as  required. 

Algorithm  C’s  running  time  is  the  same  as  A’s  running  time  plus  the  time  is  takes  to  respond  to 
( qn  +  qs )  hash  queries  and  qs  signature  queries,  and  the  time  to  transform  A’s  final  forgery  into  the 
co-CDH  solution.  Each  query  requires  an  exponentiation  in  G\ .  The  output  phase  requires  at  most 
N  additional  hash  computations,  two  inversions,  two  exponentiations,  and  N  +  1  multiplications. 
We  assume  that  exponentiation  and  inversion  in  G*i  take  time  cGl.  Hence,  the  total  running  time 
is  at  most  t  +  cGl  (qH  +  2 qs  +  N  +  4)  +  N  +  1  <  t!  as  required.  This  completes  the  proof  of 
Theorem  3.2.  □ 

Aggregate  verification  time.  Let  a  be  an  aggregate  of  the  n  signatures  a i, . . . ,  crn.  The  time  to 
verify  the  aggregate  signature  a  is  linear  in  n.  In  the  special  case  when  all  n  signatures  are  issued 
by  the  same  public  key  v,  aggregate  verification  is  faster.  One  need  only  verify  that  e(a,g2)  = 
e(v,U  ?=1H(Mi))  holds,  where  Mi, . . . ,  Mn  are  the  signed  messages. 
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4  Verifiably  Encrypted  Signatures 


Next,  we  show  an  application  of  aggregate  signatures  to  verifiably  encrypted  signatures.  Verifiably 
encrypted  signatures  are  used  in  applications  such  as  online  contract  signing  [1,  2],  Suppose  Alice 
wants  to  show  Bob  that  she  has  signed  a  message,  but  does  not  want  Bob  to  possess  her  signature 
of  that  message.  (Alice  will  give  her  signature  to  Bob  only  when  a  certain  event  has  occurred,  e.g., 
Bob  has  given  Alice  his  signature  on  the  same  message.)  Alice  can  achieve  this  by  encrypting  her 
signature  using  the  public  key  of  a  trusted  third  party,  and  sending  this  to  Bob  along  with  a  proof 
that  she  has  given  him  a  valid  encryption  of  her  signature.  Bob  can  verify  that  Alice  has  signed  the 
message,  but  cannot  deduce  any  information  about  her  signature.  Later  in  the  protocol,  if  Alice  is 
unable  or  unwilling  to  reveal  her  signature,  Bob  can  ask  the  third  party  to  reveal  Alice’s  signature. 
We  note  that  the  resulting  contract  signing  protocol  is  not  abuse-free  in  the  sense  of  [10]. 

We  show  that  a  variant  of  the  bilinear  aggregate  signature  scheme  allows  the  creation  of  very 
efficient  verifiably  encrypted  signatures. 

4.1  Verifiably  Encrypted  Signature  Security 

A  verifiably  encrypted  signature  scheme  comprises  seven  algorithms.  Three,  KeyGen,  Sign,  and 
Verify,  are  analogous  to  those  in  ordinary  signature  schemes.  The  others,  AdjKeyGen,  VESigCreate, 
VESigVerify,  and  Adjudicate,  provide  the  verifiably  encrypted  signature  capability.  The  algorithms 
are  described  below.  We  refer  to  the  trusted  third  party  as  the  adjudicator. 

Key  Generation,  Signing,  Verification.  As  in  standard  signature  schemes. 

Adjudicator  Key.  Generate  a  public-private  key  pair  ( APK ,  ASK)  for  the  adjudicator. 

VESig  Creation.  Given  a  secret  key  SK,  a  message  M,  and  an  adjudicator’s  public  key  APK, 
compute  (probabilistically)  a  verifiably  encrypted  signature  lo  on  M. 

VESig  Verification.  Given  a  public  key  PK,  a  message  M,  an  adjudicator’s  public  key  APK, 
and  a  verifiably  encrypted  signature  lo,  verify  that  a;  is  a  valid  verifiably  encrypted  signature 
on  M  under  key  PK. 

Adjudication.  Given  an  adjudicator’s  keypair  (APK,  ASK),  a  certified  public  key  PK,  and  a 
verifiably  encrypted  signature  lo  on  some  message  M,  extract  and  output  a,  an  ordinary 
signature  on  M  under  PK. 

Besides  the  ordinary  notions  of  signature  security  in  the  signature  component,  we  require  three 
security  properties  of  verifiably  encrypted  signatures:  validity,  unforgeability,  and  opacity.  We 
describe  these  properties  in  the  single  user  setting. 

Validity  requires  that  verifiably  encrypted  signatures  verify,  and  that  adjudicated  verifiably 
encrypted  signatures  verify  as  ordinary  signatures,  i.e. ,  that  VESigVerify(M ,  VESigCreate(M))  and 
Verify(M,  Adjudicate(  VESigCreate(M))  hold  for  all  M  and  for  all  properly-generated  keypairs  and 
adjudicator  keypairs.  (The  keys  provided  to  the  algorithms  are  here  omitted  for  brevity.) 

Unforgeability  requires  that  it  be  difficult  to  forge  a  valid  verifiably  encrypted  signature.  The 
advantage  in  existentially  forging  a  verifiably  encrypted  signature  of  an  algorithm  T ,  given  access 
to  a  verifiably-encrypted-signature  creation  oracle  S  and  an  adjudication  oracle  A,  along  with  a 
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hash  oracle,  is 


Adv  VSigFjr  =  Pr 


VESigVenfy(PK,  APK,  M,  u)  =  valid  : 

(PK,  SK )  Key  Gen, 

( APK ,  ASK)  AdjKeyGen , 

(M,w)  £-  Ps'A{PK,  APK) 


The  probability  is  taken  over  the  coin  tosses  of  the  key-generation  algorithms,  of  the  oracles,  and 
of  the  forger.  The  forger  is  additionally  constrained  in  that  its  forgery  on  M  must  be  nontrivial:  It 
must  not  previously  have  queried  either  oracle  at  M.  Note  that  an  ordinary  signing  oracle  is  not 
provided;  it  can  be  simulated  by  a  call  to  S  followed  by  a  call  to  A. 

Definition  4.1.  A  verifiably  encrypted  signature  forger  T  (t,  qH ,  qs,  qA,  e)-forges  a  verifiably  en¬ 
crypted  signature  if:  Algorithm  T  runs  in  time  at  most  t ;  T  makes  at  most  qH  queries  to  the  hash 
function,  at  most  qs  queries  to  the  verifiably-encrypted-signature  creation  oracle  S,  at  most  qA 
queries  to  the  adjudication  oracle  A;  and  Adv  VSigFjp  is  at  least  e.  A  verifiably  encrypted  signature 
scheme  is  (t,  qH,  qs,  qA ,  e)-secure  against  existential  forgery  if  no  forger  ( t ,  qH,  qs,  qA ,  e)-breaks  it. 

Opacity  requires  that  it  be  difficult,  given  a  verifiably  encrypted  signature,  to  extract  an  ordinary 
signature  on  the  same  message.  The  advantage  in  extracting  a  verifiably  encrypted  signature  of  an 
algorithm  £,  given  access  to  a  verifiably-encrypted-signature  creation  oracle  S  and  an  adjudication 
oracle  A,  along  with  a  hash  oracle,  is 


Adv  VSigE^  =  Pr 


VerifyiPK,  M,  a)  =  valid  : 

(PK,  SK)  £  Key  Gen, 

(APK,  ASK)  AdjKeyGen, 
(M,  a)  ^  £s'A(PK,  APK) 


The  probability  is  taken  over  the  coin  tosses  of  the  key-generation  algorithms,  of  the  oracles,  and  of 
the  forger.  The  extraction  must  be  nontrivial:  the  adversary  must  not  have  queried  the  adjudication 
oracle  A  at  M.  (It  is  allowed,  however,  to  query  S  at  M.)  Verifiably  encrypted  signature  extraction 
is  thus  no  more  difficult  than  forgery  in  the  underlying  signature  scheme. 

Definition  4.2.  An  algorithm  £  (t,  qHiQsiQA,  e)-extracts  a  verifiably  encrypted  signature  if  £  runs 
in  time  at  most  t,  makes  at  most  qH  queries  to  the  hash  function,  at  most  qs  queries  to  the 
verifiably-encrypted-signature  creation  oracle  S,  at  most  qA  queries  to  the  adjudication  oracle,  and 
AdvVSigE^  is  at  least  e.  A  verifiably  encrypted  signature  scheme  is  (t,qH,qs,qA,e)- secure  against 
extraction  if  no  algorithm  (t,  qH,  qs,  qA,  e)-extracts  it. 


4.2  Aggregate  Extraction 

Our  verifiably  encrypted  signature  scheme  depends  on  the  assumption  that  given  an  aggregate 
signature  of  k  signatures  it  is  difficult  to  extract  the  individual  signatures. 

Consider  the  bilinear  aggregate  signature  scheme  on  a  group  pair  (G i,  G2).  We  posit  that  it  is 
difficult  to  recover  the  individual  signatures  cr*  given  their  aggregate  a,  the  public  keys,  and  the 
message  hashes.  In  fact,  we  posit  that  it  is  difficult  to  recover  an  aggregate  a'  of  any  proper  subset 
of  the  signatures.  This  we  term  the  ^-element  aggregate  extraction  problem. 
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We  formalize  this  assumption  as  follows.  Let  ( G±,G2 )  be  a  bilinear  group  pair  for  co-Diffie- 
Hellman,  each  of  order  p,  with  respective  generators  g\  and  (j2-  a  computable  isomorphism  ijj  : 
G-2  —■ ►  G\  such  that  g\  =  V’(5f2))  and  a  computable  bilinear  map  e  :  Gi  x  G-j  — >  GY- 

Consider  a  /c-user  aggregate  in  this  setting.  Each  user  has  a  private  key  x%  G  Zp  and  a  public 
key  Vi  =  g G  GV  Each  user  selects  a  distinct  message  M,  G  {0, 1}*  whose  hash  is  L,  G  Gi  and 
creates  a  signature  <7,;  =  h*'-  G  Gh .  Finally,  the  signatures  are  aggregated,  yielding  a  =  rit  ai  ^  G\. 

Let  I  be  the  set  {1, . . . ,  k}.  Each  public  key  Vi  can  be  expressed  as  g%\  each  hash  hi  as  gfl ,  each 
signature  Uj  as  gx%Vl ,  and  the  aggregate  signature  a  as  gf,  where  z  =  Ylieixi9i-  The  advantage  of 
an  algorithm  £  in  extracting  a  subaggregate  from  a  Yelenrent  aggregate  is 


AdvYExtr^  =  Pr 


Cl)  A  (a' =  g(fieI'Xm))  : 

xi, . . .  >xk,yi, . . .  ,yk  Zp,  cr  <- 

W,i') 


The  probability  is  taken  over  the  choices  of  all  Xi  and  yt,  and  the  coin  tosses  of  £. 


Definition  4.3.  An  algorithm  £  ( t ,  k,  e)-extracts  a  subaggregate  from  an  /e-element  bilinear  ag¬ 
gregate  signature  if  £  runs  in  time  at  most  t  and  Adv  fc-Extr^  is  at  least  e.  An  instantiation  of  the 
bilinear  aggregate  signature  scheme  is  ( t ,  k ,  e)-secure  against  aggregate  extraction  if  no  algorithm 
(f,  k,  e)-extracts  it. 


We  will  be  particularly  concerned  with  the  case  k  =  2.  In  this  case,  the  aggregate  extraction 
problem  reduces  to  this  one:  given  g%,  g%,  g\,  and  giU+bv,  calculate  gfu.  (If  the  extractor 

outputs  gbv  instead,  we  may  recover  gfu  as  giU+bv/ gbv ■) 


4.3  Verifiably  Encrypted  Signatures  via  Aggregation 

We  motivate  our  construction  for  verifiably  encrypted  signatures  by  considering  aggregate  signa¬ 
tures  as  a  launching  point.  An  aggregate  signature  scheme  can  give  rise  to  a  verifiably  encrypted 
signature  scheme  if  it  is  difficult  to  extract  individual  signatures  from  an  aggregate,  but  easy  to 
forge  existentially  under  the  adjudicator’s  key.  Consider  the  following: 

1.  Alice  wishes  to  create  a  verifiably  encrypted  signature,  which  Bob  will  verify;  Carol  is  the  ad¬ 
judicator.  Alice  and  Carol’s  keys  are  both  generated  under  the  underlying  signature  scheme’s 
key-generation  algorithm. 

2.  Alice  creates  a  signature  a  on  M  under  her  public  key.  She  forges  a  signature  a'  on  some 
random  message  M'  under  Carol’s  public  key.  She  then  combines  a  and  a' ,  obtaining  an 
aggregate  uj.  The  verifiably  encrypted  signature  is  the  pair  (lo,M'). 

3.  Bob  validates  Alice’s  verifiably  encrypted  signature  (<v,  M ')  on  M  by  checking  that  w  is  a 
valid  aggregate  signature  by  Alice  on  M  and  by  Carol  on  M' . 

4.  Carol  adjudicates,  given  a  verifiably  encrypted  signature  (a;,  M ')  on  M  by  Alice,  by  computing 
a  signature  a'  on  M'  under  her  key,  and  removing  a'  from  the  aggregate;  what  remains  is 
Alice’s  ordinary  signature  a. 

In  the  bilinear  aggregate  signature  scheme,  it  is  difficult  to  extract  individual  signatures,  under 
the  aggregate  extraction  assumption.  Moreover,  existential  forgery  is  easy  when  the  random  oracle 
hash  function  is  set  aside:  Given  a  public  key  wGG  2  and  r  G  Zp,  '(/’( v)r  is  a  valid  signature  on  a 
message  whose  hash  is  ip(g2)r  =  g\-  Below,  we  formalize  and  prove  the  security  of  the  verifiably 
encrypted  signature  scheme  created  in  this  way. 
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4.4  The  Bilinear  Verifiably-Encrypted  Signature  Scheme 

The  bilinear  verifiably  encrypted  signature  scheme  is  built  on  the  bilinear  aggregate  signature 
scheme  of  the  previous  section.  It  shares  the  key-generation  algorithm  with  the  underlying  aggregate 
scheme.  Moreover,  the  adjudicator’s  public  and  private  information  is  simply  an  aggregate-signature 
keypair.  The  scheme  comprises  the  seven  algorithms  described  below: 

Key  Generation.  KeyGen  and  AdjKeyGen  are  the  same  as  KeyGen  in  the  co-GDH  signature 
scheme. 

Signing,  Verification.  Sign  and  Verify  are  the  same  as  in  the  co-GDH  signature  scheme. 

VESig  Creation.  Given  a  secret  key  i£Zpa  message  M  £  {0, 1}*,  and  an  adjudicator’s  public 
key  v'  £  G 2,  compute  h  <—  H(M),  where  h  £  G 1,  and  a  <—  hx.  Select  r  at  random  from  Zp 
and  set  fi  <—  V;(5,2)r  and  a'  <—  Aggregate  a  and  a'  as  u>  <—  oa'  £  G The  verifiably 

encrypted  signature  is  the  pair  (iu,/i).  (This  can  also  be  viewed  as  ElGamal  encryption  of  a 
under  the  adjudicator’s  key.) 

VESig  Verification.  Given  a  public  key  v,  a  message  M ,  an  adjudicator’s  public  key  v' ,  and  a 
verifiably  encrypted  signature  set  h  <—  H(M );  accept  if  e(uj1g2)  =  e(h,v)  ■  e(p,v') 

holds. 

Adjudication.  Given  an  adjudicator’s  public  key  v'  and  corresponding  private  key  x'  £  Zp,  a 
certified  public  key  v,  and  a  verifiably  encrypted  signature  (cu,  p)  on  some  message  M,  ensure 
that  the  verifiably  encrypted  signature  is  valid;  then  output  a  =  w/px  . 

If  the  adjudicator  does  not  first  validate  a  purported  verifiably  encrypted  signature,  a  malicious  user 
can  trick  him  into  signing  arbitrary  messages  under  his  adjudication  key.  Similarly,  the  adjudicator 
should  only  adjudicate  for  certified  public  keys  v\  we  assume  that  the  CA,  in  issuing  a  certificate 
on  v,  verifies  that  the  user  knows  the  private  key  for  v. 

It  is  easy  to  see  that  validity  holds.  A  verifiably  encrypted  signature  correctly  validates  under 
VESigVerify ,  which  is  simply  the  aggregate  signature  verification  algorithm.  Moreover,  for  any  valid 
verifiably  encrypted  signature,  e(pj/px  ,<72)  =  e(cu,g2)  ■  e(p,g2)~x  =  e(h,v)  ■  e(p,v')  ■  = 

e(h,v),  so  the  output  of  Adjudicate  is  a  valid  signature  on  message  M  under  the  key  v. 

The  next  two  theorems  prove  the  unforgeability  and  opacity  of  the  scheme. 

Theorem  4.4.  Let  G 1  and  G2  be  cyclic  groups  of  prime  order  p,  with  respective  generators  g\  and 
g2,  with  a  computable  bilinear  map  e  :  G\  x  G2  — >  Gt-  Suppose  that  the  co-GDH  signature  scheme 
is  (t1 ,  q'H,q's,  e’) -secure  against  existential  forgery  on  {G 1,  G2)  ■  Then  the  bilinear  verifiably  encrypted 
signature  scheme  is  (t,qH,qs,qA,e) -secure  against  existential  forgery  on  (G\,G2),  for  all  qH  <  q'H, 
qs  <  q's>  e  >  e'  1  ond  all  t  satisfying  t  <  t'  —  2 cGl(qs  +  qA  +  1)  ,  where  exponentiation  and  inversion 
on  G\  take  time  cGl . 

Proof.  Given  a  verifiably-encrypted-signature  forger  algorithm  V,  we  construct  a  forger  algorithm  T 
for  the  underlying  co-GDH  signature  scheme. 

We  assume  that  V  is  well-behaved  in  the  sense  that  it  always  requests  the  hash  of  a  message  M 
before  it  requests  a  verifiably  encrypted  signature  or  an  adjudication  involving  M,  and  that  it 
never  requests  adjudication  on  a  message  M  on  which  it  had  not  previously  asked  for  a  verifiably 
encrypted  signature.  It  is  trivial  to  modify  any  forger  algorithm  V  to  have  the  first  property.  The 
second  property  is  reasonable  since  the  input  to  the  adjudication  oracle  in  this  case  would  be  a 
nontrivial  verifiably  encrypted  signature  forgery;  V  can  be  modified  simply  to  output  it  and  halt. 
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The  co-GDH  forger  T  is  given  a  public  key  v,  and  has  access  to  a  signing  oracle  for  v  and  a 
hash  oracle.  It  simulates  the  challenger  and  runs  interacts  with  V  as  follows. 

R, 

Setup.  Algorithm  T  generates  a  key,  ( x',v ')  <—  KeyGen,  which  serves  as  the  adjudicator’s  key. 
Now  T  runs  V,  providing  as  input  the  public  keys  v  and  v'. 

Hash  Queries.  Algorithm  V  requests  a  hash  on  some  string  M.  Algorithm  T  makes  a  query  on  M 
to  its  own  hash  oracle,  receiving  some  value  h  E  G\ ,  with  which  it  responds  to  V’s  query. 

VerSig  Creation  Queries.  Algorithm  V  requests  a  signature  on  some  string  M.  (It  will  have 
already  queried  the  hash  oracle  at  M .)  T  queries  its  signing  oracle  (for  v)  at  M,  obtaining 
<x  E  G i.  It  then  selects  r  at  random  from  Zp,  and  returns  to  V  the  pair  (a  ■  ifi(v')r,if(g2)r). 

Adjudication  Queries.  Algorithm  V  requests  adjudication  for  a  verifiably  encrypted  sig¬ 

nature  on  a  message  M  under  key  v  and  adjudicator  key  v'.  Algorithm  T  checks  that  the 
verifiably  encrypted  signature  is  valid,  then  returns  u//j,x  . 

Output.  Finally,  V  halts,  either  declaring  failure,  in  which  case  T .  too,  declares  failure  and  halts, 
or  providing  a  valid  and  nontrivial  verifiably  encrypted  signature  on  a  message  M* . 

T  sets  a*  <—  u>*/(g*)x  which,  by  the  validity  property,  is  a  valid  co-GDH  signature  on  M* 
under  key  v. 

That  the  forgery  is  nontrivial  means  that  V  did  not  query  the  verifiably  encrypted  signature 
oracle  at  M* ,  from  which  it  follows  that  J-  did  not  query  its  signing  oracle  at  M*.  Thus 
(M*,  a*)  is  a  nontrivial  co-GDH  forgery;  algorithm  T  outputs  it  and  halts. 

It  remains  only  to  analyze  the  success  probability  and  running  time  of  T .  Algorithm  T  succeeds 
whenever  V  does,  that  is,  with  probability  at  least  e. 

Algorithm  .F’s  running  time  is  the  same  as  V’s  running  time  plus  the  time  it  takes  to  respond 
to  qH  hash  queries,  qs  verifiably-encrypted  signature  queries,  and  qA  adjudication  queries,  and  the 
time  to  transform  V’s  final  verifiably-encrypted  signature  forgery  into  a  co-GDH  signature  forgery. 
Hash  queries  impose  no  overhead.  Each  verifiably-encrypted  signature  query  requires  J-  to  perform 
two  exponentiations  in  G\.  Each  adjudication  query  requires  T  to  perform  an  exponentiation  and 
an  inversion  in  G\.  The  output  phase  also  requires  an  exponentiation  and  an  inversion.  We  assume 
that  exponentiation  and  inversion  in  G\  take  time  cGl.  Hence,  the  total  running  time  is  at  most 
t  +  2  cGl{qs  +  Qa  +  !)• 

T  queries  its  hash  oracle  whenever  V  queries  its  hash  oracle,  and  its  signing  oracle  whenever  V 
queries  its  verifiably  encrypted  signature  oracle. 

Combining  all  this,  we  see  that  if  V  ( t ,  qH,  qs,  qA,  e)-forges  a  bilinear  verifiably  encrypted  signa¬ 
ture  on  {G i,  G 2),  then  T  (t  +  2 cGl(qs  +  qA  +  1),  qH ,  qs,  e)-breaks  the  co-GDH  signature  scheme  on 
(Gi,  G2) ■  Conversely,  if  the  co-GDH  signature  scheme  is  (V,  q'H,  q's,  e') -secure,  then  the  bilinear  ver¬ 
ifiably  encrypted  signature  scheme  is  (t1  —  2 cGl(qs  +  qA  +  1),  q'H ,  q's ,  qA ,  e' (-secure  against  existential 
forgery.  □ 

Theorem  4.5.  Let  G\  and  G 2  be  cyclic  groups  of  prime  order  p,  with  respective  generators  g\  and 
<72;  with  a  computable  isomorphism  if  :  G2  — >  G\  such  that  if(g2)  =  <7i  and  a  computable  bilinear 
map  e  :  G\  x  G2  — >  Gt-  Suppose  that  the  bilinear  aggregate  signature  scheme  on  (Gi,C?2)  is 
(t\  2,  e')-secure  against  aggregate  extraction.  Then  the  bilinear  verifiably  encrypted  signature  scheme 
is  (f,  qH,  qs,  qA,  e)-secure  against  extraction  on  (Gi,G*2)  for  all  t  and  e  satisfying 

e  >  e(qA  +  1)  •  e'  and  t  <  t'  -  cGl  (qH  +  4 qs  +  2 qA  +  3)  , 
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where  e  is  the  base  of  natural  logarithms,  and  exponentiation  and  inversion  on  G\  take  time  cGl . 

Proof.  Given  a  verifiably-encrypted-signature  extractor  algorithm  V,  we  construct  an  aggregate  ex¬ 
tractor  algorithm  A.  The  co-GDH  forger  A  is  given  values  gf  and  g 2  in  G2,  gj,  gf,  and  gf  ,+  W  in  G\ . 
It  runs  V,  answering  its  oracle  calls,  and  uses  V’s  verifiably  encrypted  signature  extraction  to  cal¬ 
culate  g“7,  the  answer  to  its  own  extraction  challenge. 

Let  gi  be  a  generator  of  G 1,  and  <72  of  G2,  such  that  if(g2)  =  <71  •  Algorithm  A  is  given  gf,g^  E  G2 
and  g'l ,  gf,  gf'1+/3S  £  G\.  Its  goal  is  to  output  gf1 2 3  E  G\ .  Algorithm  A  simulates  the  challenger  and 
interacts  with  verifiably-encrypted-signature  extractor  V  as  follows. 

Setup.  Algorithm  A  sets  v  <—  gif,  the  signer’s  public  key,  and  v'  <—  g!f,  the  adjudicator’s  public 
key.  It  gives  v  and  v'  to  V. 

Hash  Queries.  At  any  time  algorithm  V  can  query  the  random  oracle  H.  To  respond  to  these 
queries,  A  maintains  a  list  of  tuples  as  explained  below.  We  refer  to 

this  list  as  the  H- list.  The  list  is  initially  empty.  When  V  queries  the  oracle  H  at  a  point 
M  £  {0, 1}*,  algorithm  A  responds  as  follows: 

1.  If  the  query  M  already  appears  on  the  H- list  in  some  tuple  (Af,  w,  b ,  c)  then  algorithm  A 
responds  with  H(M)  =  w  €  G\. 

2.  Otherwise,  A  generates  a  random  coin  c  E  {0, 1}  so  that  Pr[c  =  0]  =  1  /(qA  +  1). 

3.  Algorithm  A  picks  a  random  b  E  Zp.  If  c  =  0  holds,  A  computes  w  <—  gf  ■  gf  £  G\.  If 
c  =  1  holds,  A  computes  w  <—  gf  E  G\. 

4.  Algorithm  A  adds  the  tuple  ( M ,  w,  b,  c )  to  the  H- list  and  responds  to  V  as  H(M)  =  w. 

VerSig  Creation  Queries.  V  requests  a  verifiably-encrypted  signature  on  some  string  M  under 
challenge  key  v  and  adjudicator  key  v' .  Algorithm  A  responds  to  this  query  as  follows: 

1.  Algorithm  A  runs  the  above  algorithm  for  responding  to  IL-queries  on  M,  obtaining  the 
corresponding  tuple  ( M,w,b,c }  on  the  H- list. 

2.  A  selects  x  at  random  from  7Lp.  If  c  equals  0,  A  computes  and  returns  ( uo ,  /i)  =  (if(gf)b  ■ 
gO. 7+/35  _  ip(gP)x,gf  ■  gf).  If  c  equals  1,  A  computes  and  returns  (w,/i)  =  {gf(gf)b  ■ 
ip{g2  )x  1  gf)-  ^  is  easy  to  verify  that  (e,  p)  is  in  either  case  a  correct  verifiably  encrypted 
signature  on  the  message  with  hash  w . 

Adjudication  Queries.  Algorithm  V  requests  adjudication  for  (c o,p),  a  verifiably  encrypted  sig¬ 
nature  on  a  message  M  under  key  v  and  adjudicator  key  v' .  Algorithm  A  responds  to  this 
query  as  follows: 

1.  Algorithm  A  runs  the  above  algorithm  for  responding  to  H- queries  on  M,  obtaining  the 
corresponding  tuple  (M,w,b,c)  on  the  H- list. 

2.  Algorithm  A  checks  that  the  verifiably  encrypted  signature  is  valid.  If  it  is  not,  A 
returns  ★,  a  placeholder  value. 

3.  If  c  equals  0,  A  declares  failure  and  halts.  Otherwise,  it  computes  and  returns  a  <— 
if{gf)b.  It  is  easy  to  verify  that  a  is  the  correct  co-GDH  signature  under  key  v  on  the 
message  with  hash  w. 
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Output.  Finally,  V  halts.  It  either  concedes  failure,  in  which  case  so  does  A,  or  returns  a  nontrivial 
extracted  signature  a*  on  some  message  M* .  For  the  extraction  to  be  nontrivial,  V  must  not 
have  asked  for  adjudication  on  a  verifiably  encrypted  signature  of  M* .  Algorithm  A  runs  its 
hash  algorithm  at  M*,  obtaining  the  k  corresponding  tuples  (M* ,  w* ,  b* ,  c*)  on  the  H- list. 

A  now  proceeds  only  if  c*  =  0;  otherwise  it  declares  failure  and  halts.  Since  c*  =  0,  it  follows 
that  10*  =  gj  ■  g\* .  The  extracted  signature  a*  must  satisfy  the  co-GDH  verification  equation, 
e(a*,g2)  =  e(h*,v).  A  sets  a  <—  a*/if{v)b* .  Then 

e(a, g2)  =  e(a*,g2)  ■  e(ip(v),g2)~b*  =  e(w*,v)  ■  e(i/(g2),vpb* 

=  e(3i , v )  '  e(9i,  v)b*  ■  e(gi,v)~b*  =  e(gj,g%). 

Where  in  the  last  equality  we  substitute  v  =  gf.  Thus  (g-2,gpgi,p  is  a  valid  co-Diffie- 
Hellman  tuple,  so  cr  equals  gp' ,  the  answer  to  the  aggregate  extraction  problem;  algorithm  A 
outputs  it  and  halts. 

This  completes  the  description  of  algorithm  A.  It  remains  to  show  that  A  solves  the  given  instance 
of  the  aggregate  extraction  problem  on  (G \ .  G2)  with  probability  at  least  e' .  To  do  so,  we  analyze 
the  three  events  needed  for  A  to  succeed: 

£\:  A  does  not  abort  as  a  result  of  any  of  V’s  adjudication  queries. 

£2:  V  generates  a  valid  and  nontrivial  verifiably-encrypted  signature  extraction  (M*,< r*). 

£3:  Event  £2  occurs,  and  c*  =  0  holds,  where  c*  is  the  c-component  of  the  tuple  containing  M*  on 
the  .ff-list. 

A  succeeds  if  all  of  these  events  happen.  The  probability  Pr[£  1  A  £3]  decomposes  as 

Pr[£r  A  £3]  =  Pr[£i]  •  Pr[£2  |  £1]  •  Pr[£3  |  £1  A  £2] .  (2) 

The  following  claims  give  a  lower  bound  for  each  of  these  terms. 

Claim  4.6.  The  probability  that  algorithm  A  does  not  abort  as  a  result  ofV ’s  adjudication  queries 
is  at  least  1/e.  Hence,  Pr[£i]  >l/e. 

Proof.  Without  loss  of  generality  we  assume  that  V  does  not  ask  for  adjudication  of  the  same 
message  twice.  We  prove  by  induction  that  after  V  makes  l  signature  queries  the  probability 
that  A  does  not  abort  is  at  least  (1  —  1  /(qA  +  1))^.  The  claim  is  trivially  true  for  i  =  0.  Let  V’s 
£th  adjudication  query  be  for  verifiably  encrypted  signature  (u)^\  on  message  under  the 
challenge  key  v,  and  let  (M^,  w^\  l/^ ,  Ap  be  the  corresponding  tuple  on  the  H- list.  Then  prior  to 
issuing  the  query,  the  bit  is  independent  of  V’s  view  —  the  only  values  that  could  be  given  to  V 
that  depend  on  c/di  are  H(M^)  and  verifiably-encrypted  signatures  on  but  the  distributions 

on  these  values  are  the  same  whether  =  0  or  =  1.  Therefore,  the  probability  that  this  query 
causes  A  to  abort  is  at  most  1  /(qA  +  1).  Using  the  inductive  hypothesis  and  the  independence  of 
(pd ,  the  probability  that  A  does  not  abort  after  this  query  is  at  least  (1  —  1  /(qA  +  1))^-  This  proves 
the  inductive  claim.  Since  V  makes  at  most  qA  adjudication  queries  the  probability  that  A  does 
not  abort  as  a  result  of  all  signature  queries  is  at  least  (1  —  1  / (qA  +  l))qA  >  1  / e.  □ 

Claim  4.7.  If  algorithm  A  does  not  abort  as  a  result  of  V ’s  adjudication  queries  then  V ’s  view  is 
identical  to  its  view  in  the  real  attack.  Hence,  Pr[£2  |  £1]  >  e. 
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Proof.  The  challenge  public  key  v  given  to  V  is  from  the  same  distribution  as  public  keys  produced 
by  KeyGen ;  the  adjudicator’s  public  key  v'  given  to  V  is  from  the  same  distribution  as  the  adju¬ 
dicator  keys  produces  by  AdjKeyGen.  Responses  to  hash  queries  are  as  in  the  real  attack  since 
each  response  is  uniformly  and  independently  distributed  in  G\ .  Responses  to  verifiably-encrypted 
signature  queries  are  also  as  in  the  real  attack:  They  are  valid,  and  their  /r  components  are  uni¬ 
formly  and  independently  distributed  in  G\.  Since  A  did  not  abort  as  a  result  of  V’s  adjudication 
queries,  all  its  responses  to  those  queries  are  valid.  Therefore  V  will  produce  a  valid  and  nontrivial 
verifiably-encrypted  signature  extraction  with  probability  at  least  e.  Hence  Pr[£2  |  £1]  >  e.  □ 

Claim  4.8.  The  probability  that  algorithm  A  does  not  abort  after  V  outputs  a  valid  and  nontrivial 
verifiably-encrypted  signature  extraction  is  at  least  1  /(qA  +  1)  Hence,  Pr[<?3  |  £\  A  £2]  >  1  /(c/a  +  1)- 

Proof.  Given  that  events  £\  and  £2  happened,  algorithm  A  will  abort  only  if  V  generates  a  forgery 
( M*,a *)  for  which  the  tuple  (M* ,  w* ,  b* ,  c*)  on  the  H- list  has  c  =  1.  Since  its  extraction  is 
nontrivial,  V  could  not  have  requested  adjudication  on  any  verifiably  encrypted  signature  on  M* , 
and  c*  must  be  independent  of  V’s  current  view.  Therefore  Pr[c*  =  0  |  £\  A  £2]  >  1  /(qA  +  1)  as 
required.  □ 

Using  the  bounds  from  the  claims  above  in  equation  (2)  shows  that  A  produces  the  correct 
answer  with  probability  at  least  e/e(qA  +  1)  >  e'  as  required. 

Algorithm  Vi’s  running  time  is  the  same  as  V’s  running  time  plus  the  time  is  takes  to  respond  to 
Vi’s  oracle  queries  and  to  transform  V’s  verifiably-encrypted  signature  extraction  into  an  aggregate 
extraction.  Each  verifiably-encrypted  signature  query,  each  adjudication  query,  and  the  output 
phase  requires  A  to  run  its  H-algorithm.  It  must  therefore  run  this  algorithm  (qH+qsHqA  +  1)  times. 
Each  run  requires  an  exponentiation  in  G 1 .  Algorithm  Vl  must  run  its  verifiably-encrypted  signing 
algorithm  qs  times,  and  each  run  requires  at  most  three  exponentiation  in  G\.  Finally,  Vi’s  output 
phase  requires  at  most  one  exponentiation  and  one  inversion  in  G\ .  We  assume  that  exponentiation 
and  inversion  in  G\  take  time  cGl .  Hence,  the  total  running  time  is  at  most  t  +  cGl  ( qH  +  4 qs  + 
2 qA  +  3)  <  t'  as  required.  □ 

4.5  Observations  on  Verifiably  Encrypted  Signatures 

We  note  some  extensions  of  the  verifiably  encrypted  signature  scheme  discussed  above.  Some  of 
these  rely  for  security  on  the  fc-elenrent  aggregate  extraction  assumption  with  k  >  2. 

•  Anyone  can  convert  an  ordinary  unencrypted  signature  to  a  verifiably  encrypted  signature. 
The  same  applies  to  unencrypted  aggregate  signatures. 

•  An  adjudicator’s  private  key  can  be  shared  amongst  n  parties  using  fc-of-n  threshold  cryp¬ 
tography  [12,  11],  so  that  k  parties  are  needed  to  adjudicate  a  verifiably  encrypted  signature. 

•  A  message-signature  pair  in  the  co-GDH  signature  scheme  is  of  the  same  form  as  an  identity- 
private-key  pair  in  the  Boneh-Franklin  Identity-Based  Encryption  Scheme  [5] .  Thus  the  veri¬ 
fiably  encrypted  signature  scheme  can  potentially  be  modified  to  yield  a  verifiably  encrypted 
encryption  scheme  for  IBE  private  keys.  Verifiably  encrypted  private  keys  have  many  appli¬ 
cations  [27]. 
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5  Ring  Signatures 


Rivest,  Shamir  and  Tauman  define  ring  signature  schemes  and  construct  some  using  RSA  and 
Rabin  cryptosystems  [28].  Naor  defines  the  closely-related  notion  of  deniable  ring  authentication 
and  proposes  such  a  scheme  that  relies  only  on  the  existence  of  a  strong  encryption  function  [23]. 
We  shall  see  that  co-GDH  signatures  give  rise  to  natural  ring  signatures. 

5.1  Ring  Signatures 

Consider  a  set  U  of  users.  Each  user  u  £  U  has  a  signing  keypair  (PKU,  SKU).  A  ring  signature 
on  U  is  a  signature  that  is  constructed  using  all  the  public  keys  of  the  users  in  U,  and  a  single 
private  key  of  any  user  in  U.  A  ring  signature  has  the  property  that  a  verifier  is  convinced  that  the 
signature  was  produced  using  one  of  the  private  keys  of  U,  but  is  not  able  to  determine  which  one. 
This  property  is  called  signer- ambiguity  [28].  Applications  for  ring  signatures  include  authenticated 
(yet  repudiable)  communication  and  leaking  secrets  [28]. 

Zhang  and  Kim  [29]  devised  a  bilinear  ring  signature  in  an  identity-based  setting.  Our  scheme 
differs  from  theirs,  as  our  goal  is  to  extend  co-GDH  signatures  to  obtain  efficient  ring  signatures; 
the  system  parameters  and  key  generation  algorithm  in  our  system  are  identical  to  those  of  the 
co-GDH  scheme. 

5.2  Bilinear  Ring  Signatures 

The  ring  signature  scheme  comprises  three  algorithms:  Key  Gen,  RingSign,  and  Ring  Verify.  Recall 
gi,g2  are  generators  of  groups  Gi,  G-2  respectively,  and  e  :  G\  x  G2  — >  Gt  is  a  bilinear  map,  and  a 
computable  isomorphism  if  :  G2  — * ►  G±  exists,  with  if{g2)  =  gi •  Again  we  use  a  full-domain  hash 
function  H  :  {0, 1}*  — >  Gi.  The  security  analysis  views  H  as  a  random  oracle. 

R 

Key  Generation.  For  a  particular  user,  pick  random  x  <—  Zp,  and  compute  v  <—  g% .  The  user’s 
public  key  is  v  £  G2.  The  user’s  secret  key  is  x  £  Zp. 

Ring  Signing.  Given  public  keys  v±, . . .  ,vn  £  G2,  a  message  M  £  {0, 1}*,  and  a  private  key  x 

corresponding  to  one  of  the  public  keys  vs  for  some  s,  choose  random  a*  ■£-  Zp  for  all  i  7^  s. 
Compute  h  <—  H(M )  £  G\  and  set 


(js  —  w(IR) 

'  i^s 

For  all  i  /  s  let  <—  .  Output  the  ring  signature  a  =  (<7i, . . . ,  an)  £  Gf . 

Ring  Verification.  Given  public  keys  v\, . . .  ,vn  £  G2,  a  message  M  £  {0, 1}*,  and  a  ring  signa¬ 
ture  a,  compute  h  <—  H(M)  and  verify  that  e(h,  <72)  =  n"=i  e(oj,Ui). 

Using  the  bilinearity  and  nondegeneracy  of  the  pairing  e,  it  is  easy  to  show  that  a  signature 
produced  by  the  RingSign  algorithm  will  verify  under  the  Ring  Verify  algorithm. 

5.3  Security 

There  are  two  aspects  a  security  analysis  for  ring  signatures  we  must  consider.  Firstly,  signer 
ambiguity  must  be  ensured.  We  show  that  the  identity  of  the  signer  is  unconditionally  protected. 
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Theorem  5.1.  For  any  algorithm  A ,  any  set  of  users  JJ ,  and  a  random  u  6  U,  the  probability 
Pr[v4(a)  =  u]  is  at  most  1/|I/|,  where  a  is  any  ring  signature  on  U  generated  with  private  key  SKU. 

Proof.  The  theorem  follows  from  a  simple  probability  argument:  for  any  h  6  G\,  and  any  s, 
1  <  s  <  n,  the  distribution  {gf1 , . . . ,  gfn  :  ai  <—  Zp  for  i  /  s,as  chosen  such  that  fX'Li  9i'  =  M 
identical  to  the  distribution  {g®1 , . . .  ,gfn  :  n!=i  9\  =  since  the  value  of  any  one  of  the  afs  is 
uniquely  determined  by  the  values  of  the  other  afs.  □ 

Secondly,  we  need  to  examine  the  scheme’s  resistance  to  forgery.  We  adopt  the  security  model 
of  Rivest,  Shamir  and  Taurnan  [28].  Consider  the  following  game  played  between  an  adversary  and 
a  challenger.  The  adversary  is  given  the  public  keys  vi, . . .  ,vn  of  a  set  of  users  U,  and  is  given 
oracle  access  to  h  and  a  ring-signing  oracle.  The  adversary  may  work  adaptively.  The  goal  of  the 
adversary  is  to  output  a  valid  ring  signature  on  U  of  a  message  M  subject  to  the  condition  that 
M  has  never  been  presented  to  the  ring-signing  oracle.  An  adversary  A’s  advantage  AdvRingSig^ 
in  existentially  forging  a  bilinear  ring  signature  is  the  probability,  taken  over  the  coin  tosses  of  the 
key-generation  algorithm  and  of  the  forger,  that  A  succeeds  in  creating  a  valid  ring  signature  in 
the  above  game. 

Theorem  5.2.  Suppose  F  is  a  ( t ' ,  e')-algorithm  that  can  produce  a  forgery  of  a  ring  signature  on  a 
set  of  users  of  size  n.  Then  there  exists  an  (t,  e)  -algorithm  that  can  solve  the  co-CDH  problem  where 
t  <  2t'  +  2cG2(2n  +  qH  +  nqs)  and  e  >  ((e'/e)(l  +  qs))2,  where  F  issues  at  most  qs  ring- signature 
queries  and  at  most  qH  hash  queries,  and  exponentiation  and  inversion  on  G2  take  time  cG2 . 

Proof.  The  co-CDH  problem  can  be  solved  by  first  solving  two  random  instances  of  the  following 
problem:  Given  gxb,g2  (and  fj\-.  92  ),  compute  g \.  We  shall  construct  an  algorithm  A  that  solves 
this  problem.  This  is  easy  if  a  =  0.  In  what  follows,  we  assume  a/0. 

Initially  A  picks  x'2 ,  •  ■  ■ ,  xn  at  random  from  Zp  and  sets  x\  =  l.  It  sets  Vi  =  (g%)Xi.  Algorithm 
F  is  given  the  public  keys  v\, ...  ,vn.  Without  loss  of  generality  we  may  assume  F  submits  distinct 
queries  (as  previous  replies  can  be  cached);  that  for  every  ring-signing  query  on  a  message  M,  F 
has  previously  issued  a  hash  query  for  M ;  and  that  F  issues  a  hash  query  on  the  message  on  which 
it  attempts  to  forge  a  signature  some  time  before  giving  its  final  output. 

On  a  hash  query,  A  flips  a  coin  that  shows  0  with  probability  p  and  1  otherwise  (p  shall  be 

determined  later).  Then  A  picks  a  random  r  <—  Zp,  and  if  the  coins  shows  0,  A  returns  (g i)r, 
otherwise  it  returns  ■ 

Suppose  F  issues  a  ring  sign  query  for  a  message  M.  By  assumption,  A  has  previously  issued  a 
hash  query  for  M.  If  the  coin  A  flipped  for  this  /r-query  showed  0,  then  A  fails  and  exits.  Otherwise 
A  had  returned  H(M )  =  ^(g^Y  for  some  r.  In  this  case  A  chooses  random  a2,...,an  <—  Zp, 
computes  a\  =  r  —  (02X2  +  . . .  +  anxn ),  and  returns  the  signature  a  =  (g®1 , . . . ,  gfn)- 

Eventually  T  outputs  a  forgery  (a±, . . .  ,an)  for  a  message  M.  Again  by  assumption,  T  has 
previously  issued  a  /r-query  for  M.  If  the  coin  flipped  by  A  for  this  query  did  not  show  0  then  A 
fails.  Otherwise  H(M)  =  gfbr  for  some  r  chosen  by  A ,  and  A  outputs  the  rth  root  of  oxcr-A2  ■  •  •  crnXn. 

Algorithm  T  cannot  distinguish  between  A’s  simulation  and  real  life.  Also,  A  will  not  fail  with 
probability  pqs(  1  —  p)  which  is  maximized  when  p  =  qs/{qs  +  1),  giving  a  bound  of  (l/e)(l  +  qs). 
If  it  does  not  fail  and  T  successfully  forges  a  ring  signature  then  A  is  successful  and  outputs  g\. 
Algorithm  A  requires  n  exponentiations  on  G2  in  setup,  one  exponentiation  for  each  of  FA  hash 
queries,  n  exponentiations  for  each  of  FA  signature  queries,  and  n  exponentiations  in  the  output 
phase,  so  its  running  time  is  FA  running  time  plus  cG2(2n  +  qH  +  nqs).  □ 
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5.4  Observations  on  Ring  Signatures 

Any  ring  signature  scheme  restricts  to  an  ordinary  signature  scheme  when  n  =  1.  Our  scheme 
restricts  to  a  short  signature  scheme  similar  to  the  co-GDH  scheme  [6].  In  this  modified  co-GDH 
scheme,  a  equals  h 1  !x  rather  than  hx,  and  one  verifies  that  e(h,  g2)  =  e(a,v)  rather  than  that 
e(<r,g2)  =  e(h,v). 

Bresson  et  al.  [7]  extend  Rivest-Shamir-Taunran  ring  signatures  to  obtain  threshold  and  ad-hoc 
ring  signatures.  However,  bilinear  ring  signatures  have  interesting  properties  that  do  not  appear 
to  be  shared  by  ring  signatures  in  general.  For  any  set  of  users  U  with  u  £  U,  anyone  can  convert 
a  modified  co-GDH  signature  by  u  into  a  ring  signature  by  U.  Specifically,  to  convert  a  modified 
co-GDH  signature  o\  on  M  for  public  key  v\  into  a  ring  signature  a  =  (a\ . . . . ,  a'n)  on  M  for  public 

keys  v\, . . . ,  vn,  we  choose  rj  Zp  for  2  <  i  <  n,  and  set  a\  <—  a\  Wf=2  and  a\  <—  ip(vfri) 

for  2  <  i  <  n.  More  generally,  anyone  can  further  anonymize  a  ring  signature  by  adding  users  to 
U. 

6  Conclusions 

We  introduced  the  concept  of  aggregate  signatures  and  constructed  an  efficient  aggregate  signature 
scheme  based  on  bilinear  maps.  Key  generation,  aggregation,  and  verification  require  no  interaction. 
We  proved  security  of  the  system  in  a  model  that  gives  the  adversary  his  choice  of  public  keys  and 
messages  to  forge.  For  security,  we  introduced  the  additional  constraint  that  an  aggregate  signature 
is  valid  only  if  it  is  an  aggregation  of  signatures  on  distinct  messages.  This  constraint  is  satisfied 
naturally  for  the  applications  we  have  in  mind.  More  generally,  the  constraint  can  be  satisfied  by 
prepending  the  public  key  to  the  message  prior  to  signing. 

We  gave  several  applications  for  aggregate  signatures.  For  example,  they  can  be  used  to  reduce 
the  size  of  certificate  chains  and  reduce  communication  bandwidth  in  protocols  such  as  SBGP.  We 
also  showed  that  our  specific  aggregate  signature  scheme  gives  verifiably  encrypted  signatures. 

Previous  signature  constructions  using  bilinear  maps  [6,  19,  8,  4]  only  required  a  gap  Diffie- 
Hellman  group  (i.e.,  DDH  easy,  but  CDH  hard).  The  signature  constructions  in  this  paper  require 
the  extra  structure  provided  by  the  bilinear  map.  These  constructions  are  an  example  where  a 
bilinear  map  provides  more  power  than  a  generic  gap  Diffie-Hellman  group. 
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Abstract 

We  describe  a  short  signature  scheme  which  is  existentially  unforgeable  under  a  chosen 
message  attack  without  using  random  oracles.  The  security  of  our  scheme  depends  on  a  new 
complexity  assumption  we  call  the  Strong  Diffie- Heilman  assumption.  This  assumption  has 
similar  properties  to  the  Strong  RSA  assumption,  hence  the  name.  Strong  RSA  was  previously 
used  to  construct  signature  schemes  without  random  oracles.  However,  signatures  generated  by 
our  scheme  are  much  shorter  and  simpler  than  signatures  from  schemes  based  on  Strong  RSA. 
Furthermore,  our  scheme  provides  a  limited  form  of  message  recovery. 


1  Introduction 

Boneh,  Lynn,  and  Shacham  (BLS)  [BLS01]  recently  proposed  a  short  digital  signature  scheme 
where  signatures  are  about  half  the  size  of  DSA  signatures  with  the  same  level  of  security.  Security 
is  based  on  the  Computational  Difhe-Hellman  (CDH)  assumption  on  certain  elliptic  curves.  The 
scheme  is  shown  to  be  existentially  unforgeable  under  a  chosen  message  attack  in  the  random  oracle 
model  [BR93]. 

In  this  paper  we  describe  a  signature  scheme  where  signatures  are  almost  as  short  as  BLS  signa¬ 
tures,  but  whose  security  does  not  require  random  oracles.  We  prove  security  of  our  scheme  using 
a  complexity  assumption  we  call  the  Strong  Diffie-Hellman  assumption,  or  SDH  for  short.  Roughly 
speaking,  the  g-SDH  assumption  in  a  group  G  of  prime  order  p  states  that  the  following  problem 
is  intractable:  given  g,gx,g(x  \  ...,g(x< ''l  G  G  as  input,  output  a  pair  (c,  glKx+c))  where  c  G  Z*. 
Precise  definitions  are  given  in  Section  2.3.  Using  this  assumption  we  construct  a  signature  scheme 
that  is  existentially  unforgeable  under  a  chosen  message  attack  without  using  random  oracles. 

Currently,  the  most  practical  signature  schemes  secure  without  random  oracles  [GHR99,  CSOO] 
are  based  on  the  Strong  RSA  assumption  (given  an  RSA  modulus  N  and  s  G  2,*N  it  is  difficult 
to  construct  a  non-trivial  pair  (c,  s1/0)  where  c  G  Z).  Roughly  speaking,  what  makes  Strong  RSA 
so  useful  for  constructing  secure  signature  schemes  is  the  following  property:  given  a  Strong  RSA 
problem  instance  ( N ,  s)  it  is  possible  to  construct  a  new  instance  (N,  s')  with  q  known  solutions 
(cj,  (s')1/Cl),  where  the  construction  of  any  other  solution  (c,  (s')1/0)  makes  it  possible  to  solve  the 
original  problem  instance.  This  property  provides  a  way  to  prove  security  against  a  chosen  message 
attack.  In  Section  3.1  we  show  that  the  q-SDH  problem  has  a  similar  property.  Hence,  g-SDH  may 
be  viewed  as  a  discrete  logarithm  analogue  of  the  Strong  RSA  assumption.  We  believe  that  the 
properties  of  g-SDH  make  it  a  useful  tool  for  constructing  cryptographic  systems  and  we  expect  to 
see  many  other  systems  based  on  it. 

To  gain  some  confidence  in  the  g-SDH  assumption  we  provide  in  Section  5  a  lower  bound  on 
the  computational  complexity  of  solving  the  g-SDH  problem  in  a  generic  group  model.  This  shows 
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that  no  generic  attack  on  (/-SDH  is  possible.  Mitsunari,  Sakai,  and  Kasahara  [MSK02]  previously 
used  a  weaker  variant  of  the  (/-SDH  assumption  to  construct  a  traitor  tracing  scheme.  The  ideas  in 
their  paper  are  nice,  and  we  use  some  of  them  here.  However,  their  application  to  tracing  traitors 
appears  to  be  insecure  [TSNZ03]. 

We  present  our  secure  signature  scheme  in  Section  3  and  prove  its  security  against  existential 
forgery  under  chosen  message  attack.  The  resulting  signatures  are  as  short  as  DSA  signatures,  but 
are  provably  secure  in  the  absence  of  random  oracles.  Our  signatures  also  support  limited  message 
recovery,  which  makes  it  possible  to  further  reduce  the  total  length  of  a  message/signature  pair.  In 
Section  4  we  show  that  with  random  oracles  the  (/-SDH  assumption  gives  even  shorter  signatures. 
A  related  system  using  random  oracles  was  recently  described  by  Zhang  et  al.  [ZSNS04]. 

We  refer  to  [BLS01]  for  applications  of  short  signatures.  We  only  mention  that  short  digital 
signatures  are  needed  in  environments  with  stringent  bandwidth  constraints,  such  as  bar-coded 
digital  signatures  on  postage  stamps  [NSOO,  PVOO].  We  also  note  that  Patarin  et  al.  [PCG01, 
CDF03]  construct  short  signatures  whose  security  depends  on  the  Hidden  Field  Equation  (HFE) 
problem. 

2  Preliminaries 

Before  presenting  our  results  we  briefly  review  two  notions  of  security  for  signature  schemes,  review 
the  definition  for  groups  equipped  with  a  bilinear  map,  and  precisely  state  the  (/-SDH  assumption. 

2.1  Secure  Signature  Schemes 

A  signature  scheme  is  made  up  of  three  algorithms,  Key  Gen,  Sign ,  and  Verify,  for  generating  keys, 
signing,  and  verifying  signatures,  respectively. 

Strong  Existential  Unforgeability 

The  standard  notion  of  security  for  a  signature  scheme  is  called  existential  unforgeability  under  a 
chosen  message  attack  [GMR88].  We  consider  a  slightly  stronger  notion  of  security,  called  strong 
existential  unforgeability  [ADR02],  which  is  defined  using  the  following  game  between  a  challenger 
and  an  adversary  A: 

Setup:  The  challenger  runs  algorithm  KeyGen  to  obtain  a  public  key  PK  and  a  private 
key  SK.  The  adversary  A  is  given  PK. 

Queries:  Proceeding  adaptively,  A  requests  signatures  on  at  most  qs  messages  of  his  choice 
Mi, ... ,  Mqa  E  {0, 1}*,  under  PK.  The  challenger  responds  to  each  query  with  a  signa¬ 
ture  a i  =  Sign{SK,  Mi). 

Output:  Eventually,  A  outputs  a  pair  (M,  a)  and  wins  the  game  if 

(1)  (M,  a)  is  not  any  of  (AR,  ui), . . . ,  (Mqs,aqf),  and 

(2)  Verify(PK,  M,  a)  =  valid. 

We  define  AdvSig^  to  be  the  probability  that  A  wins  in  the  above  game,  taken  over  the  coin  tosses 
made  by  A  and  the  challenger. 

Definition  2.1.  A  forger  A  (t,  qs,  e)-breaks  a  signature  scheme  if  A  runs  in  time  at  most  t,  A  makes 
at  most  qs  signature  queries,  and  AdvSig_q  is  at  least  e.  A  signature  scheme  is  (t,  qs,  e)-existentially 
unforgeable  under  an  adaptive  chosen  message  attack  if  no  forger  (t,  qs,  e)-breaks  it. 
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When  proving  security  in  the  random  oracle  model  we  add  a  fourth  parameter  qH  denoting  an 
upper  bound  on  the  number  of  queries  that  the  adversary  A  makes  to  the  random  oracle. 

We  note  that  the  definition  above  captures  a  stronger  version  of  existential  unforgeability  than 
the  standard  one:  we  require  that  the  adversary  cannot  even  generate  a  new  signature  on  a  pre¬ 
viously  signed  message.  This  property  is  required  for  some  applications  [ADR02,  Sah99,  CHK04], 
All  our  signature  schemes  satisfy  this  stronger  security  notion. 

Weak  Chosen  Message  Attacks 

We  will  also  use  a  weaker  notion  of  security  which  we  call  existential  unforgeability  under  a  weak 
chosen  message  attack.  Here  we  require  that  the  adversary  submit  all  signature  queries  before 
seeing  the  public  key.  This  notion  is  defined  using  the  following  game  between  a  challenger  and  an 
adversary  A: 

Query:  A  sends  the  challenger  a  list  of  qs  messages  Mi, . . . ,  Mqs  £  {0, 1}*. 

Response:  The  challenger  runs  algorithm  KeyGen  to  generate  a  public  key  PK  and  private 
key  SK.  Next,  the  challenger  generates  signatures  cq  =  Sign(SK,  M,)  for  i  =  1, . . . ,  qs. 
The  challenger  then  gives  A  the  public  key  PK  and  the  qs  signatures  oq , . . . ,  oqs . 
Output:  Algorithm  A  outputs  a  pair  (M,a)  and  wins  the  game  if 

(1)  M  is  not  any  of  Mi, . . . ,  Mqs ,  and 

(2)  Verify(PK,  M,a)  =  valid. 

We  define  AdvW-Sig^  to  be  the  probability  that  A  wins  in  the  above  game,  taken  over  the  coin 
tosses  of  A  and  the  challenger. 

Definition  2.2.  A  forger  A  (f,  qs,  e)-weakly  breaks  a  signature  scheme  if  A  runs  in  time  at  most 
t,  A  makes  at  most  qs  signature  queries,  and  AdvW-Sig_4  is  at  least  e.  A  signature  scheme  is 
(t,  qs,  e)-existentially  unforgeable  under  a  weak  chosen  message  attack  if  no  forger  (t,  qs,  e)-weakly 
breaks  it. 

2.2  Bilinear  Groups 

Signature  verification  in  our  scheme  requires  a  bilinear  map.  We  briefly  review  the  necessary  facts 
about  bilinear  maps  and  bilinear  map  groups.  We  follow  the  notation  in  [BLS01]: 

1.  Oi  and  G2  are  two  (multiplicative)  cyclic  groups  of  prime  order  p; 

2.  g\  is  a  generator  of  Gi  and  g 2  is  a  generator  of  O2; 

3.  ip  is  an  isomorphism  from  G2  to  Gi,  with  ip(g2)  =  91',  and 

4.  e  is  a  bilinear  map  e  :  Gi  x  G2  — >  G t- 

For  simplicity  one  can  set  Gi  =  G2.  However,  as  in  [BLS01],  we  allow  for  the  more  general  case 
where  Gi  7^  G2  so  that  we  can  take  advantage  of  certain  families  of  elliptic  curves  to  obtain  short 
signatures.  Specifically,  elements  of  Gi  have  a  short  representation  whereas  elements  of  G2  may 
not.  The  proofs  of  security  require  an  efficiently  computable  isomorphism  ip  :  G2  — * ►  Gi.  When 
Gi  =  G2  and  g\  =  52  one  could  take  ip  to  be  the  identity  map.  On  elliptic  curves  we  can  use  the 
trace  map  as  ip. 

Let  thus  Gi  and  G2  be  two  groups  as  above,  with  an  additional  group  G t  such  that  |Gi|  = 
IG2 1  =  |Gt|.  A  bilinear  map  is  a  map  e  :  Gi  x  G2  — ►  G t  with  the  following  properties: 

1.  Bilinear:  for  all  u  £  Gi,u  £  G2  and  a,  b  £  Z,  e(ua,vb)  =  e(u,v)ab. 

2.  Non-degenerate:  e(pi, 52)  /  1. 
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We  say  that  (Gi,  G2)  are  bilinear  groups  if  there  exists  a  group  G t,  an  isomorphism  ip  :  G2  — > 
Gi,  and  a  bilinear  map  e  :  Gi  x  G2  — >  G t  as  above,  and  e,  ip,  and  the  group  action  in  Gi,  G2,  and 
G t  can  be  computed  efficiently. 

Joux  and  Nguyen  [JN01]  showed  that  an  efficiently  computable  bilinear  map  e  provides  an 
algorithm  for  solving  the  Decision  Diffie- Heilman  problem  (DDH).  Our  results  can  be  stated  using 
a  generic  algorithm  for  DDH.  Nevertheless,  for  the  sake  of  concreteness  we  instead  describe  our 
results  by  directly  referring  to  the  bilinear  map. 

2.3  The  Strong  Diffie-Hellman  Assumption 

Before  describing  the  new  signature  schemes,  we  first  state  precisely  the  hardness  assumption  on 
which  they  are  based.  Let  Gi,G2  be  two  cyclic  groups  of  prime  order  p,  where  possibly  Gi  =  G2. 
Let  g\  be  a  generator  of  Gi  and  52  a  generator  of  G2  such  that  g\  =  ip(g2)- 

(/-Strong  Diffie-Hellman  Problem.  The  (/-SDH  problem  in  (Gi,G2)  is  defined  as  follows: 
given  a  (q  +  2)-tuple  (<71,  (72,  gf  1 9*2  \  ■  ■  ■  ■>  92  as  input  where  as  above  g\  =  ip(g2),  output  a 
pair  (c,  g\^x+<^)  where  c  G  Z*.  An  algorithm  A  has  advantage  e  in  solving  (/-SDH  in  (Gi,G2)  if 

Pi'  A(g1,g2,g%,...,gixq))  =  (c,  gp+c)  >e 

where  the  probability  is  over  the  random  choice  of  generator  52  G  G2  with  <71  =  ip{g2),  the  random 
choice  of  x  in  Z*,  and  the  random  bits  consumed  by  A. 

Definition  2.3.  We  say  that  the  (q,  t,  e)-SDH  assumption  holds  in  (Gi,  G2)  if  no  t-tirne  algorithm 
has  advantage  at  least  e  in  solving  the  (/-SDH  problem  in  (Gi,G2). 

Occasionally  we  drop  the  t  and  e  and  refer  to  the  (/-SDH  assumption  rather  than  the  (q,  t,  e)- 
SDH  assumption.  As  we  will  see  in  the  next  section  the  (/-SDH  assumption  has  similar  properties 
to  the  Strong  RSA  problem  and  we  therefore  view  (/-SDH  as  a  discrete  logarithm  analogue  of  the 
Strong  RSA  assumption. 

To  provide  some  confidence  in  the  (/-SDH  assumption,  we  prove  in  Section  5  a  lower  bound  on 
the  complexity  of  solving  the  (/-SDH  problem  in  a  generic  group.  Furthermore,  we  note  that  the 
Strong  Diffie-Hellman  problem  has  a  simple  random  self-reduction  in  (Gi,G2). 

A  weaker  version  of  the  (/-SDH  assumption  was  previously  used  by  Mitsunari,  Sakai,  and  Kasa- 
hara  [MSK02]  to  construct  a  traitor  tracing  system  (see  [TSNZ03]  for  an  analysis).  Using  our 
notation,  their  version  of  the  assumption  requires  Algorithm  A  to  output  g ^  ;  for  a  given  input 

value  c.  In  the  assumption  above  we  allow  A  to  choose  c.  When  c  is  pre-specified  the  (/-SDH 
problem  is  equivalent  to  the  following  problem:  given  (51, 52,  >  S2  1  •  •  •  >gf9)  output  g\^x .  We  note 

that  when  A  is  allowed  to  choose  c  no  such  equivalence  is  known. 

3  Short  Signatures  Without  Random  Oracles 

We  now  construct  a  fully  secure  short  signature  scheme  in  the  standard  model  using  the  (/-SDH 
assumption.  We  consider  this  to  be  the  main  result  of  the  paper. 

Let  (Gi,G2)  be  bilinear  groups  where  |Gi|  =  | G2 1  =  p  for  some  prime  p.  For  the  moment  we 
assume  that  the  messages  m  to  be  signed  are  elements  in  Z*,  but  as  we  mention  in  Section  3.5,  the 
domain  can  be  extended  to  all  of  {0, 1}*  using  a  collision  resistant  hash  function  H  :  {0, 1}*  — >  Z*. 
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Key  generation:  Pick  a  random  generator  52  G  G 2  and  set  g\  =  ^(52)  •  Pick  random  x,  y  <—  Z*, 
and  compute  u  ^  g  G2  and  v  <—  g\  E  O2.  Also  compute  z  <—  e(<7i,  (72)  £  Gy.  The  public 
key  is  (gi,  g2,u,v,  z).  The  secret  key  is  (. x,y ). 

Signing:  Given  a  secret  key  x,  y  G  Z*  and  a  message  m  G  Z*,  pick  a  random  r  G  Z*  and  compute 
ex  <—  gV(x+m+2'r)  ^  Here  l/(x  +  m  +  yr)  is  computed  modulo  p.  In  the  unlikely  event 
that  x  +  m  +  yr  =  0  we  try  again  with  a  different  random  r.  The  signature  is  (<r,  r ). 

Verification:  Given  a  public  key  (gi,g2,u,v,  z),  a  message  m  G  Z*,  and  a  signature  (cr,r),  verify 
that 

e(cr,  u  •  glff  vr)  =  z 

If  the  equality  holds  the  result  is  valid;  otherwise  the  result  is  invalid. 

Public  Key  Integrity.  Observe  that  the  g\  and  z  components  of  the  public  key  can  be  computed 
from  other  parts  of  the  public  key  and  are  thus  redundant.  They  are  included  in  the  public  key 
for  efficiency  reasons,  in  order  to  dispense  the  verifier  from  performing  these  computations.  It  is 
up  to  the  Certifying  Authority  (CA)  to  verify  that  the  relations  g\  =  ^(<72)  and  z  =  e(g\ ,  (72)  hold 
before  issuing  a  certificate.  Alternatively,  the  verifier  can  perform  these  checks  when  verifying  the 
certificate  for  a  given  public-key.  Since  this  is  a  one-time  check  we  do  not  explicitly  include  it  in 
the  verification  algorithm. 

Signature  Length.  A  signature  contains  two  elements  (a,  r),  each  of  length  approximately 
l°g2(p)  bits,  therefore  the  total  signature  length  is  approximately  2  log2 (p)  ■  When  using  the  el¬ 
liptic  curves  described  in  [BLS01]  we  obtain  a  signature  whose  length  is  approximately  the  same 
as  a  DSA  signature  with  the  same  security,  but  which  is  provably  existentially  unforgeable  under 
a  chosen  message  attack  without  the  random  oracle  model. 

Performance.  Key  and  signature  generation  times  are  comparable  to  BLS  signatures.  Verifica¬ 
tion  time  is  faster  since  verification  requires  only  one  pairing  and  one  multi-exponentiation.  The 
value  z  =  e( <71,52)  only  needs  to  be  computed  (or  verified)  at  certification  time.  In  comparison, 
BLS  signature  verification  requires  two  pairing  computations.  Since  exponentiation  tends  to  be 
significantly  faster  than  pairing,  signature  verification  is  faster  than  in  the  BLS  system. 

Security.  The  following  theorem  shows  that  the  scheme  above  is  existentially  unforgeable  in  the 
strong  sense  under  chosen  message  attacks,  provided  that  the  5-SDH  assumption  holds  in  (Gi,G2). 

Theorem  3.1.  Suppose  the  ( q ,  t! ,  e’)-SDH  assumption  holds  in  (Gi,  G2).  Then  the  signature  scheme 
above  is  (t,  qs,  e)  -secure  against  existential  forgery  under  a  chosen  message  attack  provided  that 

qs  <  q  ,  e  >  2(e/  +  qs/p)  ~  2e/  and  t  <  t'  —  Q(q2T) 

where  T  is  the  maximum  time  for  an  exponentiation  in  G\  and  G2. 

Proof.  We  prove  the  theorem  using  two  lemmas.  In  Lemma  3.2,  we  first  describe  a  simplified 
signature  scheme  and  prove  its  existential  unforgeability  against  weak  chosen  message  attacks  under 
the  (7-SDH  assumption.  In  Lemma  3.3,  we  then  show  that  the  security  of  the  weak  scheme  implies 
the  security  of  the  full  scheme.  From  these  results  (Lemmas  3.2  and  3.3),  Theorem  3.1  follows 
easily.  We  present  the  proof  in  two  steps  since  the  construction  used  to  prove  Lemma  3.2  will  be 
used  later  on  in  the  paper.  □ 
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3.1  A  Weakly  Secure  Short  Signature  Scheme 

We  first  show  how  the  g-SDH  assumption  can  be  used  to  construct  an  existentially  unforgeable 
scheme  under  a  weak  chosen  message  attack.  This  construction  demonstrates  the  main  properties 
of  the  (/-SDH  assumption.  In  the  next  section  we  show  that  the  security  of  this  weak  scheme  implies 
the  security  of  the  full  scheme  above. 

The  weakly  secure  short  signature  scheme  is  as  follows.  As  before,  let  (Gi,G2)  be  bilinear 
groups  where  |Gi|  =  |  G-2 1  —  V  f°r  some  prime  p.  For  the  moment  we  assume  that  the  messages  m 
to  be  signed  are  elements  in  Z*. 

Ft 

Key  generation:  Pick  a  random  generator  (72  G  G2  and  set  g±  =  if{g 2).  Pick  random  x  <—  Z*, 
and  compute  v  <—  g%  G  O2  and  z  e(g±,  <72)  £  Gt-  The  public  key  is  (gi,  <72,  u,  z).  The  secret 
key  is  x. 

Signing:  Given  a  secret  key  x  G  Z*  and  a  message  m  G  Z*,  output  the  signature  a  <—  g^x+m^  g 
Gi.  Here  1  /(x  +  m)  is  computed  modulo  p.  By  convention  in  this  context  we  define  1/0  to 
be  0  so  that  in  the  unlikely  event  that  x  +  m  =  0  we  have  a  <—  1 . 

Verification:  Given  a  public  key  (<71,  <72,  v,  z),  a  message  m  G  Z*,  and  a  signature  a  E  Gi,  verify 
that 

e(<r,v-  g 2l)  =  z 

If  equality  holds  output  valid.  If  a  =  1  and  v  ■  g™  =  1  output  valid. 

Otherwise,  output  invalid. 

We  show  that  the  basic  signature  scheme  above  is  existentially  unforgeable  under  a  weak  chosen 
message  attack.  The  proof  of  the  following  lemma  uses  a  similar  method  to  the  proof  of  Theorem  3.5 
of  Mitsunari  et  al.  [MSK02] . 

Lemma  3.2.  Suppose  the  (q,t' ,  e)-SDH  assumption  holds  in  (Gi,G2).  Then  the  basic  signature 
scheme  above  is  (t,  qs,  e)  -secure  against  existential  forgery  under  a  weak  chosen  message  attack 
provided  that 

qs  <  q  and  t  <t'  —  Q(q2T) 
where  T  is  the  maximum  time  for  an  exponentiation  in  G\  and  G2. 

Proof.  Assume  A  is  a  forger  that  (f,  qs,  e)-breaks  the  signature  scheme.  We  construct  an  algorithm 
B  that,  by  interacting  with  A,  solves  the  g-SDH  problem  in  time  t!  with  advantage  e.  Algorithm 
B  is  given  a  random  instance  (<71,  <72,  Ai, . . . ,  Aq)  of  the  g-SDH  problem,  where  A*  =  g^f  ^  G  G2  for 
i  =  1, . . . ,  g  and  for  some  unknown  x  G  Z*.  For  convenience  we  set  Aq  =  g2-  Algorithm  B' s  goal  is 

to  produce  a  pair  (c,  g\^x+c^)  for  some  c  G  Z*.  Algorithm  B  does  so  by  interacting  with  the  forger 
A  as  follows: 

Query:  Algorithm  A  outputs  a  list  of  distinct  qs  messages  mi, . . . ,  mqg  G  Z*,  where  qs  <  q.  Since 
A  must  reveal  its  queries  up  front,  we  may  assume  that  A  outputs  exactly  q  —  1  messages  to 
be  signed  (if  the  actual  number  is  less,  we  can  always  virtually  reduce  the  value  of  q  so  that 
q  =  qs  +  1). 

Response:  B  must  respond  with  a  public  key  and  signatures  on  the  q  —  1  messages  from  A.  Let 
f(y)  be  the  polynomial  f(y)  =  Yi'IZH'y  +  mi)-  Expand  f(y)  and  write  f(y)  =  YhZq  aiVl 
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where  ao, ,  aq-\  £  Zp  are  the  coefficients  of  the  polynomial  f(y).  Compute: 

h~f[A°-'=g^={!/2r 

i= 0  i=l 

Also,  let  g\  =  Ai.g'2)  and  z!  =  e(g,1,g,2).  The  public  key  given  to  A  is  (g\ .  g2,  h,  z1).  which  has 
the  correct  distribution.  Note  that  we  may  assume  that  f(x )  A  0  since,  otherwise,  x  =  —rrii 
for  some  i  which  means  that  B  just  obtained  the  secret  key  x. 

Next,  for  each  i  =  1, . . .  q  —  1,  Algorithm  B  must  generate  a  signature  cr*  on  mj.  To  do  so,  let 
fi(y )  be  the  polynomial  ft(y)  =  /(y)/(y  +  mi )  =  nj=i +  mjj)-  As  before,  we  expand  .// 
and  write  fi(y)  =  Pjyj  ■  Compute 

II  Af  =  ^  =  (92)1/{X+mi)  G 

3=0 

Observe  that  at  =  ip(Si)  £  Gi  is  a  valid  signature  on  m  under  the  public  key  (g[,  g2,  h,  z'). 
Algorithm  B  gives  A  the  q  —  1  signatures  a\, ,  aq-\. 

Output:  Algorithm  A  returns  a  forgery  (m*,  cr*)  such  that  <r*  £  Gi  is  a  valid  signature  on  m*  £  Z* 
and  m*  0  {mi  . . . ,  mq- 1}  since  there  is  only  one  valid  signature  per  message.  In  other  words, 
e(cr*,/r  •  {g'2)m*)  =  e{^,cf2).  Since  h  =  ( g2)x  we  have  that  e(<r*,  (g2)x+m*)  =  e(g[,g'2)  and 
therefore 

a*  =  (y'jVU+m*)  =  (01)/(x)/(a!+m*)  (1) 


Using  long  division  we  write  the  polynomial  /  as  /(y)  =  'y(y)(y+m*)+'y_1  for  some  polynomial 
7(2/)  =  Si=o  7 it/1  and  some  7_x  £  Zp.  Then  the  rational  fraction  f(y) / (y+m*)  in  the  exponent 
on  the  right  side  of  Equation  (1)  can  be  written  as 


f(y)/(y  +  m*) 


7-i 

y  +  m* 


<?— 2 

+ 7*0* 


i=0 


+EL“o^’ 


and  hence 


o’*  —  5i 


Note  that  7_2  A  0,  since  f(y)  =  nf=i(y  +  mi)  and  A-  {mu  ■  ■  ■  imq- 1},  as  thus  (y  +  m* ) 
does  not  divide  /(y).  Then  algorithm  I?  computes 


re 


(  g— 2 

o*  •  ip{Ai 
V  i=0 


1/7-1 


1 — ft 


7-1  v^q  — 2  9  2 


1/7-1 


=  ffl 


x+m*  Yli—0  7ia;I 


'  .9i 


n* 


-7 


l/(i+m,) 

=  01 


t=0 


and  returns  ( m*,w; )  as  the  solution  to  the  (/-SDH  instance. 
The  claimed  bounds  are  obvious  by  construction  of  the  reduction. 


□ 


3.2  From  Weak  Security  To  Full  Security 

We  now  present  a  reduction  from  the  security  of  the  basic  scheme  of  Lemma  3.2  to  the  security 
of  the  full  signature  scheme  described  at  the  onset  of  Section  3.  This  will  complete  the  proof  of 
Theorem  3.1. 
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Lemma  3.3.  Suppose  that  the  basic  signature  scheme  of  Lemma  3.2  is  (t1 ,  qs,  e') -weakly  secure. 
Then  the  full  signature  scheme  is  (t,  qs ,  e)- secure  against  existential  forgery  under  a  chosen  message 
attack  provided  that 

e  >  2(e  +  qs/p)  ~  2.e  and  t  <  t'  —  Q(qsT) 

where  T  is  the  maximum  time  for  an  exponentiation  in  G\  and  G2- 

We  first  give  some  intuition  for  the  proof.  Suppose  A  is  a  forger  for  the  full  scheme  under  a 
chosen  message  attack.  We  build  a  forger  B  for  the  weak  scheme  under  a  weak  chosen  message 
attack.  Forger  B  starts  by  requesting  signatures  on  random  messages  wq, . . . ,  wq  £  Z*.  In  response, 
it  is  given  a  public  key  (<?i,  <72,  u,  z)  and  signatures  a\, . . . ,  aqs  £  Gi  for  the  weak  scheme.  In 
principle,  B  could  create  a  public  key  for  the  full  scheme  by  picking  a  random  y  £  Z*  and  giving  A 
the  public  key  (gi,g2,u,  g\,  z).  Now,  when  A  issues  a  chosen  message  query  for  a  message  m;  £  Z *, 
forger  B  could  choose  an  rt  £  Zp  such  that  rnt  +  yry  maps  to  wy.  Then  (oy,7y)  is  a  valid  signature 
on  mi  for  the  full  scheme  and  hence  a  proper  response  to  *4’s  chosen  message  query.  Eventually, 
A  outputs  a  forgery  (m*, <7*, r*).  Then  (m*  +  yr*,cr*)  is  a  valid  message/signature  pair  for  the 
weak  scheme.  In  principle,  13  could  output  this  pair  as  its  existential  forgery  on  the  weak  scheme. 
The  problem  is  that  to*  +  yr*  might  be  in  {wq, . . . ,  wqs}  in  which  case  (to*  +  yr* ,  cr*)  is  an  invalid 
existential  forgery.  Dealing  with  this  case  complicates  the  proof  and  forces  us  to  consider  two  types 
of  adversaries.  The  full  proof  is  given  below. 

Proof  of  Lemma  3.3.  Assume  A  is  a  forger  that  (t,  qs,  e)-breaks  the  full  signature  scheme.  We 
construct  an  algorithm  B  that  ( t qs,  e/2  —  gs/p)-weakly  breaks  the  basic  signature  scheme  of 
Lemma  3.2. 

Before  describing  Algorithm  B  we  distinguish  between  two  types  of  forgers  that  A  can  emulate. 
Let  (hi,  h2 ,  u,  v,  z )  be  the  public  key  given  to  forger  A  where  u  =  yf  and  v  =  Suppose  A  asks  for 
signatures  on  messages  m±, . . . ,  mQs  G  Z*  and  is  given  signatures  (ay,  rf)  for  i  =  1, . . . ,  qs  on  these 
messages.  Let  Wi  =  mi  +  y?y  and  let  (TO*,cr*,r*)  be  the  forgery  produced  by  A.  We  distinguish 
between  two  types  of  forgers: 

Type-1  forger:  a  forger  that  either 

(i)  makes  a  signature  query  for  the  message  to  =  —x,  or 

(ii)  outputs  a  forgery  where  to*  +  yr*  0  {wq, . . . ,  wqs}. 

Type-2  forger:  a  forger  that  both 

(i)  never  makes  a  signature  query  for  the  message  to  =  —x,  and 

(ii)  outputs  a  forgery  where  to*  +  yr*  =  wy  for  some  i  G  {1, . . . ,  qs}. 

We  show  that  either  forger  can  be  used  to  forge  signatures  for  the  weak  signature  scheme  of 
Lemma  3.2.  However,  the  reduction  works  differently  for  each  forger  type.  Therefore,  initially  B 
will  choose  a  random  bit  cmo(je  £  {1,2}  that  indicates  its  guess  for  the  type  of  forger  that  A  will 
emulate.  The  simulation  proceeds  differently  for  each  mode. 

We  are  now  ready  to  describe  Algorithm  B.  It  produces  a  forgery  for  the  signature  scheme  of 
Lemma  3.2  as  follows: 

Setup:  Algorithm  B  first  picks  a  random  bit  cmode  £  { 1 , 2} .  Next,  B  sends  to  its  own  challenger 
a  list  of  qs  random  messages  wq, . . .  ,wqg  G  Z*  for  which  it  requests  a  signature.  The  chal¬ 
lenger  responds  with  a  valid  public  key  (g\,g-2,  u,  z )  and  signatures  a  1, . . . ,  crqs  £  Gi  on  these 
messages.  We  know  that  e(cq,  gff'u)  =  e(<q,  <72)  =  z  for  alH  =  1, . . . ,  qs.  Then: 

•  (If  cmode  =  1).  B  picks  a  random  y  G  Z*  and  gives  A  the  public  key  PK\  =  (gi,g2,u,  g%,z). 
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•  (If  cmode  =  2 ).  B  picks  a  random  x  G  Z*  and  gives  A  the  public  key  PK 2  =  (gi,  g-2,  yf  >  z)- 

In  either  case,  we  note  that  B  provides  the  adversary  A  with  a  valid  public  key  (g\,  g2,  U,  V,  z). 

Signature  queries:  The  forger  A  can  issue  up  to  qs  signature  queries  in  an  adaptive  fashion.  In 
order  to  respond,  B  maintains  a  list  H- list  of  tuples  ( rrii ,  rj,  IT)  and  a  query  counter  i  which 
is  initially  set  to  0.  Upon  receiving  a  signature  query  for  to,  Algorithm  B  increments  t  by 
one.  Then: 


•  (If  cmode  =  !)•  Check  if  g^171  =  u.  If  so,  then  B  just  obtained  the  private  key  for  the  public 
key  (51,  g2,  u,  z)  it  was  given,  which  allows  it  to  forge  the  signature  on  any  message  of  its 
choice.  At  this  point  B  successfully  terminates  the  simulation. 

Otherwise,  set  r e  =  {we  —  m)/y  G  Z*.  In  the  very  unlikely  event  that  re  =  0,  Algorithm  B 
reports  failure  and  aborts.  Otherwise,  Algorithm  B  gives  A  the  signature  ( ae,re )•  This  is  a 
valid  signature  on  to  under  PK\  since  re  is  uniform  in  Z*  and 

e(ae,  U  ■  g™  ■  Vrt )  =  e(ae,  u  ■  g™  ■  gfl)  =  e(ae,u  ■  g™1)  =  e(gi,g2)  =  z 

•  (If  cmode  =  2).  Set  re  =  (x  +  m)/we  G  Z*.  If  re  =  0,  Algorithm  B  reports  failure  and  aborts. 

Otherwise,  give  A  the  signature  {o)/ri ,re).  This  is  a  valid  signature  on  m  under  PK2  since 
re  is  uniform  in  Z*  and 

e(<j],r\  U  ■  g'2  ■  Vn)  =  e{a],ri,  g%  ■  g ^  ■  un )  =  e(ae,  g^u)  =  e(gl,g2)  =  z 

In  either  case  if  B  does  not  abort  it  responds  with  a  valid  signature  on  m. 

In  either  case  Algorithm  B  adds  the  tuple  (m,re,  g™Vre)  to  the  H- list. 

Output:  Eventually,  A  returns  a  forgery  (m*,cr*,r*),  where  (<7*,r*)  is  a  valid  forgery  distinct 
from  any  previously  given  signature  on  message  m*.  Note  that  by  adding  dummy  queries 
as  necessary,  we  may  assume  that  A  made  exactly  qs  signature  queries.  Let  IT*  <—  g™*Vr* . 
Algorithm  B  searches  the  H- list  for  a  tuple  whose  rightmost  component  is  equal  to  IT* .  There 
are  two  possibilities: 

Type-1  forgery:  No  tuple  of  the  form  (•,  •,  IT*)  appears  on  the  H- list. 

Type-2  forgery:  The  H- list  contains  at  least  one  tuple  (mg,rj,  Wj)  such  that  Wj  =  IT*. 

Let  6type  1  if  A  produced  a  type-1  forgery,  or  A  made  a  signature  query  for  a  message  m 
such  that  =  U.  In  all  other  cases,  set  &type  2.  If  &type  A  Anode  then  B  reports  failure 
and  aborts.  Otherwise,  B  outputs  an  existential  forgery  on  the  basic  signature  scheme  as 
follows: 


•  (If  Cmode  =  hype  =  1).  If  A  made  a  signature  query  for  a  message  m  such  that  g A"'  =  U 
then  B  is  already  done.  Therefore,  we  assume  A  produced  a  type-1  forgery.  Since  the  forgery 
is  valid,  we  have 


e(ffi,S2)  =  e(u*,  U  ■  g'2*  ■  Vr*) 


e(cr*, 


m*-\-yr* 

u  ■  g2 


Let  re*  =  to*  +  yr*.  It  follows  that  (tc*,cr*)  is  a  valid  message/signature  pair  in  the  basic 
signature  scheme.  Furthermore,  it  is  a  valid  existential  forgery  for  the  basic  scheme  since  in 
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a  type-1  forgery  Algorithm  B  did  not  request  a  signature  on  the  message  w *  £  Z*.  Indeed, 
£>  only  requested  signatures  on  messages  wj  =  rrij  +  yrj  where  (rrij ,  rj ,  g™3 )  is  a  tuple  in  the 
H- list,  but  g'2*  is  not  equal  to  any  g^3  on  the  iL-list.  Algorithm  B  outputs  (tc*,cT*)  as  the 
required  existential  forgery. 

•  (If  cmode  =  &type  =  2).  Let  (rrij,  rj,  W j)  be  a  tuple  on  the  H- list  where  Wj  =  If7*-  Since 
V  =  u  we  know  that  g^1  uri  =  g™*  ur* .  Write  u  =  g%  for  some  t  £  Z*  so  that  rrij  +  rrj  = 
m *  +  rr*.  We  know  that  (rrij,  rj)  /  (m*,r*),  otherwise  the  forgery  would  be  identical  to  a 
previously  given  signature  on  the  query  message  rrij.  Since  g™jurj  =  g™*ur*  it  follows  that 
rrij  A  m*  and  rj  A  r*.  Therefore,  r  =  (m*  —  m,j)/(rj  —  r*)  £  Z*.  Hence,  £>  just  recovered 
the  private  key,  r,  for  the  public  key  (g\,g2,u,z)  it  was  given.  Algorithm  B  can  now  forge  a 
signature  on  any  message  of  its  choice. 

This  completes  the  description  of  Algorithm  B.  A  standard  argument  shows  that  if  B  does  not 
abort,  then,  from  the  viewpoint  of  A,  the  simulation  provided  by  B  is  indistinguishable  from  a  real 
attack  scenario.  In  particular,  (i)  the  view  from  A  is  independent  of  the  value  of  cmode ,  (h)  the 
public  keys  are  uniformly  distributed,  and  (iii)  the  signatures  are  correct.  Therefore,  A  produces  a 
valid  forgery  in  time  t  with  probability  at  least  e. 

It  remains  to  bound  the  probability  that  B  does  not  abort.  We  argue  as  follows: 

•  Conditioned  on  the  event  cmo(je  =  6type  =  1 ,  Algorithm  B  aborts  if  A  issued  a  signature  query 
mg  =  wg.  This  happens  with  probability  at  most  qs/p. 

•  Conditioned  on  the  event  cmode  =  ^type  =  2,  Algorithm  B  does  not  abort. 

Since  cmocie  is  independent  of  &type  we  have  that  Pr[cmo(je  =  ^type]  =  1/2-  It  now  follows  that  B 
produces  a  valid  forgery  with  probability  at  least  e/2  —  qs/p,  as  required.  □ 

Since  in  the  full  scheme  a  single  message  has  many  valid  signatures,  it  is  worth  repeating  that 
the  full  signature  scheme  is  existentially  unforgeable  in  the  strong  sense:  the  adversary  cannot  make 
any  forgery,  even  on  messages  which  are  already  signed. 

3.3  Relation  to  Chameleon  Hash  Signatures 

It  is  instructive  to  consider  the  relation  between  the  full  signature  scheme  above  and  a  signature  con¬ 
struction  based  on  the  Strong  RSA  assumption  due  to  Gennaro,  Halevi,  and  Rabin  (GHR)  [GHR99]. 
GHR  signatures  are  pairs  (r,  s1/^(m>r)j  where  H  is  a  Chameleon  hash  [KROO],  r  is  random  in  some 
range,  and  arithmetic  is  done  modulo  an  RSA  modulus  N.  Looking  closely,  one  can  see  some 
parallels  between  the  proof  of  security  in  Lemma  3.3  above  and  the  proof  of  security  in  [GHR99]. 
There  are  three  interesting  points  to  make: 

•  The  m  +  yr  component  in  our  signature  scheme  provides  us  with  the  functionality  of  a 
Chameleon  hash:  given  m,  we  can  choose  r  so  that  m  +  yr  maps  to  some  predefined  value 
of  our  choice.  This  makes  it  possible  to  handle  the  chosen  message  attack.  Embedding  the 
hash  m  +  yr  directly  in  the  signature  scheme  results  in  a  much  more  efficient  construction 
than  using  an  explicit  Chameleon  hash  (which  requires  additional  exponentiations).  This  is 
not  known  to  be  possible  with  Strong  RSA  signatures. 

•  One  difficulty  with  GHR  signatures  is  that  given  a  solution  (6,  s1/6)  to  the  Strong  RSA 
problem  one  can  deduce  another  solution,  e.g.  (3,  s1/3).  Thus,  given  a  GHR  signature  on  one 
message  it  possible  to  deduce  a  GHR  signature  on  another  message  (see  [GHR99,  CNOO]  for 
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details).  Gennaro  et  al.  solve  this  problem  by  ensuring  that  H(m,  r )  always  maps  to  a  prime; 
However,  that  makes  it  difficult  to  compute  the  hash  (a  different  solution  is  given  in  [CSOO] ) . 
This  issue  does  not  come  up  at  all  in  our  signature  scheme  above. 

•  We  obtain  short  signatures  since,  unlike  Strong  RSA,  the  (/-SDH  assumption  applies  to  groups 
with  a  short  representation. 

Thus,  we  see  that  Strong  Diffie-Hellman  leads  to  signatures  that  are  simpler,  more  efficient,  and 
shorter  than  their  Strong  RSA  counterparts. 

3.4  Limited  Message  Recovery 

We  now  describe  another  useful  property  of  the  signature  schemes  whereby  the  total  size  of  signed 
messages  can  be  further  reduced  at  the  cost  of  increasing  the  verification  time.  The  technique 
applies  equally  well  to  the  fully  secure  signature  scheme  as  to  the  weakly  secure  one. 

A  standard  technique  for  shortening  the  total  length  of  message/signature  pairs  is  to  encode  a 
part  of  the  message  in  the  signature  [MVV97].  Signatures  based  on  trapdoor  permutations  support 
very  efficient  message  recovery. 

At  the  other  end  of  the  spectrum,  a  trivial  signature  compression  mechanism  that  applies  to  any 
signature  scheme  is  as  follows:  Rather  than  transmit  a  message/signature  pair  (M,  a),  the  sender 
transmits  {M ,  a)  where  M  is  the  same  as  M  except  that  the  last  t  bits  are  truncated.  In  other 
words,  M  is  t  bits  shorter  than  M .  To  verify  (M,  a)  the  verifier  tries  all  2t  possible  values  for  the 
truncated  bits  and  accepts  the  signature  if  one  of  them  verifies.  To  reconstruct  the  original  signed 
message  M,  the  verifier  appends  to  M  the  t  bits  for  which  the  signature  verified. 

This  trivial  method  shows  that  the  pair  (M,  a)  can  be  shortened  by  f-bits  at  the  cost  of  increasing 
verification  time  by  a  factor  of  24.  For  our  signature  scheme  we  obtain  a  better  tradeoff:  the  pair 
(M,  a)  can  be  shortened  by  t  bits  at  the  cost  of  increasing  verification  time  by  a  factor  of  2^2  only. 
We  refer  to  this  property  as  limited  message  recovery. 


Limited  Message  Recovery.  Limited  message  recovery  applies  to  both  the  full  signature  scheme 
and  the  weakly  secure  signature  scheme  of  Lemma  3.2.  For  simplicity,  we  only  show  how  limited 
message  recovery  applies  to  the  full  signature  scheme.  Assume  messages  are  k- bit  strings  represented 
as  integers  in  Z*.  Let  (gi,g2,  u,  v,  z)  be  a  public  key  in  the  full  scheme — although  for  this  application 
one  might  prefer  to  abbreviate  the  public  key  as  (g2,u,v)  and  let  the  verifier  derive  g±  and  z. 
Suppose  we  are  given  the  signed  message  (to,  <t,  r)  where  to  is  a  truncation  of  the  last  t  bits  of 
to.  £  Z*.  Thus  to  =  to  •  2t  T  S  for  some  integer  0  <  5  <  2*.  Our  goal  is  to  verify  the  signed  message 
(to,  a,  r )  and  to  reconstruct  the  missing  bits  5  in  time  2*/2.  To  do  so,  we  first  rewrite  the  verification 
equation  e(<r,  u  ■  vr  ■  g ™)  =  e(<7i,  <72)  as 


e(a,g2)m 


e(<7,  u  ■  vr) 


Substituting  m  =  m  ■  2l  +  5  we  obtain 


e(v,g-2)S 


e(ffi,g2) 

e(<r,  u  ■  vr  ■  g™2*  ) 


(2) 


Now,  we  say  that  (to,  a,  r)  is  valid  if  there  exists  an  integer  6  £  [0,24)  satisfying  Equation  (2). 
Finding  such  a  5  takes  time  approximately  2^2  using  Pollard’s  Lambda  method  [MVV97,  p.  128] 
for  computing  discrete  logarithms.  Thus,  we  can  verify  the  signature  and  recover  the  t  missing 
message  bits  in  time  2*/2,  as  required. 
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Ultra  Short  Weakly  Secure  Signatures.  Obvious  applications  of  limited  message  recovery  are 
situations  where  bandwidth  is  extremely  limited,  such  as  when  the  signature  is  an  authenticator 
that  is  to  be  typed-in  by  a  human.  The  messages  in  such  applications  are  typically  chosen  and 
signed  by  a  central  authority,  so  that  adaptive  chosen  message  attacks  are  typically  not  a  concern. 
It  is  safe  in  those  cases  to  use  the  weakly  secure  signature  scheme  of  Lemma  3.2,  and  apply 
limited  message  recovery  to  further  shrink  the  already  compact  signatures  it  produces.  Specifically, 
using  f-bit  truncation  as  above  we  obtain  a  total  signature  overhead  of  (160  —  t)  bits  for  common 
security  parameters,  at  the  cost  of  requiring  2*/2  arithmetic  operations  for  signature  verification. 
We  emphasize  that  the  security  of  this  system  does  not  rely  on  random  oracles. 

3.5  Arbitrary  Message  Signing 

We  can  extend  our  signature  schemes  to  sign  arbitrary  messages  in  {0, 1}*,  as  opposed  to  merely 
messages  in  Z*,  by  first  hashing  the  message  using  a  collision-resistant  hash  function  H  :  {0, 1}*  — > 
Z*  prior  to  both  signing  and  verifying.  A  standard  argument  shows  that  if  the  scheme  above  is 
secure  against  existential  forgery  under  a  chosen  message  attack  (in  the  strong  sense)  then  so  is 
the  scheme  with  the  hash.  The  result  is  a  signature  scheme  for  arbitrary  messages  in  {0,1}*. 
We  note  that  there  is  no  need  for  a  full  domain  hash  into  Z*;  a  collision  resistant  hash  function 
H  :  {0, 1}*  — >  {1, . . . ,  2b}  for  2b  <  p  is  sufficient  for  the  security  proof.  This  transformation  applies 
to  both  the  fully  and  the  weakly  secure  signature  schemes  described  above. 

4  Shorter  Signatures  With  Random  Oracles 

For  completeness  we  show  that  the  weakly  secure  signature  scheme  of  Lemma  3.2  gives  rise  to  very 
efficient  and  fully  secure  short  signatures  in  the  random  oracle  model.  To  do  so,  we  show  a  general 
transformation  from  any  existentially  unforgeable  signature  scheme  under  a  weak  chosen  message 
attack  into  an  existentially  unforgeable  signature  scheme  under  a  standard  chosen  message  attack 
(in  the  strong  sense) ,  in  the  random  oracle  model.  This  gives  a  very  efficient  short  signature  scheme 
based  on  g-SDH  in  the  random  oracle  model.  We  analyze  our  construction  using  a  method  of  Katz 
and  Wang  [KW03]  which  gives  a  very  tight  reduction  to  the  security  of  the  underlying  signature. 
We  note  that  a  closely  related  system  with  a  weaker  security  analysis  was  independently  discovered 
by  Zhang  et  al.  [ZSNS04]. 

Let  ( KeyGen ,  Sign,  Verify)  be  an  existentially  unforgeable  signature  under  a  weak  chosen 
message  attack.  We  assume  that  the  scheme  signs  messages  in  some  finite  set  S  and  that  the 
private  keys  are  in  some  set  II.  We  need  two  hash  functions  H\  :  II  x  {0, 1}*  — >  {0, 1}  and 
H-2  :  {0, 1}  x  {0,1}*  — >  S  that  will  be  viewed  as  random  oracles  in  the  security  analysis.  The 
hash-signature  scheme  is  as  follows: 

Key  generation:  Same  as  KeyGen.  The  public  key  is  PK;  The  secret  key  is  SK  E  II. 

Signing:  Given  a  secret  key  SK,  and  given  a  message  M  E  {0,1}*,  compute  b  <—  H\{SK,M)  E 
{0, 1}  and  m  <—  Pd2(b,M)  E  S.  Output  the  signature  [b,  Sign(m)).  Note  that  signatures  are 
one  bit  longer  than  in  the  underlying  signature  scheme. 

Verification:  Given  a  public  key  PK,  a  message  M  E  {0, 1}*,  and  a  signature  (b,  a),  output  valid 
if  Verify(PK,  Pd2{b,  M ),  a)  =  valid. 

Theorem  4.1  below  proves  security  of  the  scheme.  Note  that  the  security  reduction  in  Theo¬ 
rem  4.1  is  tight,  namely,  an  attacker  on  the  hash-signature  scheme  with  success  probability  e  is 
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converted  to  an  attacker  on  the  underlying  signature  with  success  probability  approximately  e/2. 
Proofs  of  signature  schemes  in  the  random  oracle  model  are  often  far  less  tight. 

Theorem  4.1.  Suppose  (Key Gen,  Sign,  Verify)  is  (t1 ,  q's,  e')- existentially  unforgeable  under  a  weak 
chosen  message  attack.  Then  the  corresponding  hash- signature  scheme  is  ( t ,  qs,qH,  e) -secure  against 
existential  forgery  under  an  adaptive  chosen  message  attack,  in  the  random  oracle  model,  whenever 
qs  +  Qh  <  q's,  and  for  all  all  t  and  e  satisfying 

e  >  2e//(l  —  jw)  ~  2e'  and  t  <  t!  —  o(t') 

2. j 

Proof.  Assume  A  is  a  forger  that  (t,  qs,qH,  e)-breaks  the  hash-signature  scheme  (in  the  random  ora¬ 
cle  model).  We  construct  an  algorithm  B  that  interacts  with  A  and  (t' ,  q's,  e^-breaks  the  underlying 
signature  scheme.  Algorithm  B  works  as  follows: 

Setup:  Algorithm  B  picks  q's  random  and  independent  messages  m\, . . . ,  m. q's  in  S  and  sends  them 
to  the  challenger.  The  challenger  responds  with  a  public  key  PK  and  signatures  a i, . . .  ,crq. / 
on  mi, . . . ,  mqig.  Algorithm  B  gives  PK  to  Algorithm  A. 

Hash  queries:  At  any  time  Algorithm  A  can  query  the  hash  functions  H\  and  H2.  It  can  query 
these  functions  qH  times  each.  Since  B  can  maintain  tables  to  ensure  that  repeated  queries 
are  answered  consistently,  we  assume  without  loss  of  generality  that  A  never  queries  on  the 
same  input  twice. 

To  respond  to  a  query  for  H\(K,  M)  Algorithm  B  first  checks  if  K  =  SK by  attempting  to  sign 
a  random  message  using  K.  If  the  signature  is  valid  then  B  outputs  that  message/signature 
pair  as  an  existential  forgery  and  terminates.  Otherwise,  B  picks  a  random  bit  b  £  {0, 1}  and 
tells  A  that  H\(K,M)  =  b. 

To  respond  to  a  query  for  H‘i(c,  M)  Algorithm  B  maintains  a  list  of  tuples  ( Mi,bi,i )  called 
the  -ff-list,  and  a  counter  1  which  is  initially  set  to  0.  The  H- list  is  initially  empty.  When 
responding  to  a  query  for  M )  we  set  things  up  so  that  we  know  the  signature  on  either 
#2(0,  M)  or  H2(l,  M)  but  A  will  not  know  which  one.  More  precisely,  to  respond  to  the 
query  H2(c,M)  Algorithm  B  does  the  following: 

1.  If  M  is  not  on  the  left  hand  side  of  any  tuple  in  the  H- list  then  pick  a  random  bit 
b  £  {0, 1},  set  i  <— •  t  +  1 ,  and  add  (M,  b,  t)  to  the  H- list. 

2.  Let  ( M,b,j )  be  the  entry  on  the  H- list  corresponding  to  M.  Then,  if  b  =  c  output 
H2 (c,  M)  =  mj  (for  which  we  know  that  a.j  is  a  valid  signature).  Otherwise,  pick  a 
random  message  m  £  S  and  output  #2(0  M )  =  m.  Note  that  j  <  qs  +  qH  <  q's  (since  l 
is  always  less  than  this  value)  so  that  mj  is  well  defined. 

Signature  queries:  A  can  issue  up  to  qs  signature  queries.  To  respond  to  a  signature  query  for 
M  £  £  Algorithm  B  first  runs  the  algorithm  for  responding  to  a  hash  query  for  H2(0,M ) 
(hence  the  total  number  of  H2  queries  is  qs  +  qH ).  Let  ( M,b,j )  be  the  entry  on  the  H- list 
corresponding  to  M.  Algorithm  B  responds  with  ( b,aj )  as  the  signature  on  M.  This  is  a 
valid  signature  on  M  since  H2(b,M)  =  mj  and  aj  is  a  valid  signature  on  m.j.  Note  that  this 
defines  H\  (SK,  M)  =  b  even  though  B  does  not  know  SK. 

Output:  Eventually,  A  returns  a  forgery,  (M*,  (6*,  ay)),  such  that  (6*,cr*)  is  a  valid  signature  on 
M*  in  the  hash-signature  scheme  and  A  did  not  previously  obtain  (b*,cr*)  from  B  in  response 
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to  a  signature  query  on  M* .  It  follows  that  <7*  is  a  valid  signature  in  the  underlying  signature 
scheme  of  the  message  m*  =  H2(b*,  M*).  If  m*  £  {mi, . . .  ,mq's}  then  B  reports  failure  and 
aborts.  Otherwise,  it  outputs  (m*,<7*)  as  the  existential  forgery  for  the  underlying  signature 
scheme 

Algorithm  B  simulates  the  random  oracles  and  signature  oracle  perfectly  for  A.  Therefore  A 
produces  a  valid  forgery  for  the  hash-signature  scheme  with  probability  at  least  e.  It  remains 
to  bound  the  probability  that  m*  £  {mi, . . . ,  mq/ }.  Let  (M*,6,  j)  be  the  entry  on  the  H- list 
corresponding  to  M*.  First,  consider  the  case  where  A  never  issued  a  signature  query  for  M*.  In 
this  case  the  bit  b  is  independent  of  A/s  view.  Therefore,  Pr[6*  =  b]  =  1/2.  Next,  note  that  if 
6*  =  b  then,  by  construction,  m*  =  H'Ab*.  M*)  =  nrij  and  therefore  in  this  case  B  will  fail.  When 
6*  A  b,  by  construction,  H-2(b *,  M*)  is  chosen  at  random  in  S  and  therefore,  in  this  case,  B  will  fail 
with  probability  at  most  q's/ |£|.  Now,  in  the  case  where  A  did  issue  a  signature  query  for  M*,  we 
necessarily  have  6*  A  b,  otherwise  A’s  forgery  would  be  a  replay  of  B's  response.  £>’ s  failure  rate  in 
this  case  is  thus  also  at  most  g{/|S|.  Thus,  in  all  cases,  it  follows  that  B  succeeds  with  probability 
at  least 

Pr [success (£>)]  >  ^  •  (1  —  ^-)  >  e 

as  required.  □ 

We  note  that  in  the  proof  above  H\  can  be  replaced  with  a  Pseudo  Random  Function  (PRF) 
and  does  not  need  to  be  modeled  as  a  random  oracle.  However,  modeling  H2  as  a  random  oracles 
appears  to  be  unavoidable. 

Applying  Theorem  4.1  to  the  weakly  secure  scheme  of  Lemma  3.2  gives  an  efficient  short  signa¬ 
ture  existentially  unforgeable  under  a  standard  chosen  message  attack  in  the  random  oracle  model 
assuming  (gs+gw+l)-SDH.  For  a  public  key  (<71,  g2,  v  =  g%,  z)  and  a  hash  function  H  :  {0, 1}*  — >  Z* 

a  signature  on  a  message  m  is  defined  as  the  value  a  <—  gV(x+'fRLm))  ^  q1  concatenated  with  the 
bit  b  £  {0, 1}.  To  verify  the  signature,  check  that  e(a ,  v  ■  =  z  =  e(<7i,  772).  We  see  that 

signature  length  is  essentially  the  same  as  in  BLS  signatures,  but  verification  time  is  approximately 
half  that  of  BLS.  During  verification,  exponentiation  is  always  base  <72  which  enables  a  further 
speed-up  by  pre-computing  certain  powers  of  <72- 

Full  Domain  Hash.  Another  method  for  converting  a  signature  scheme  secure  under  a  weak 
chosen  message  attack  into  a  scheme  secure  under  a  standard  chosen  message  attack  is  to  simply 
apply  Sign  and  Verify  to  H(M)  rather  than  M.  In  other  words,  we  hash  M  £  {0,1}*  using  a 
full  domain  hash  H  prior  to  signing  and  verifying.  Security  in  the  random  oracle  model  is  shown 
using  a  similar  argument  to  Coron’s  analysis  [CorOO]  of  the  Full  Domain  Hash  [BR96].  However, 
the  resulting  reduction  is  not  tight:  an  attacker  on  this  hash-then-sign  signature  with  success 
probability  e  yields  an  attacker  on  the  underlying  signature  with  success  probability  approximately 
e/qs-  We  note,  however,  that  these  proofs  are  set  in  the  random  oracle  model  and  therefore  it  is 
not  clear  whether  the  efficiency  of  the  security  reduction  is  relevant  to  actual  security  in  the  real 
world.  Therefore,  since  this  full  domain  hash  signature  scheme  is  slightly  simpler  that  the  system 
in  Theorem  4.1  it  might  be  preferable  to  use  it  rather  than  the  system  of  Theorem  4.1.  When 
we  apply  the  full  domain  hash  to  the  weakly  secure  scheme  of  Lemma  3.2,  we  obtain  a  secure 
signature  under  a  standard  chosen  message  attack  assuming  ( qs  +  qH  +  1)-SDH.  A  signature  is 
one  element,  namely  a  <—  g^Sx+H(m))  ^  kefore)  signature  verification  is  twice  as  fast  as 

in  BLS  signatures.  As  mentioned  above,  a  similar  scheme  was  independently  proposed  by  Zhang 
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et  al.  [ZSNS04].  We  also  note  that,  in  the  random  oracle  model,  security  of  this  full  domain  hash 
scheme  can  be  proven  under  a  slightly  weaker  complexity  assumption  than  (/-SDH,  namely  that  the 
value  c  in  the  (/-SDH  assumption  is  pre-specified  rather  than  chosen  by  the  adversary.  However, 
the  resulting  security  reduction  is  far  less  efficient. 

5  Generic  Security  of  the  g-SDH  Assumption 

To  provide  more  confidence  in  the  (/-SDH  assumption  we  prove  a  lower  bound  on  the  computational 
complexity  of  the  (/-SDH  problem  for  generic  groups  in  the  sense  of  Shoup  [Sho97]. 

In  the  generic  group  model,  elements  of  Gi,  G2,  and  G t  appear  to  be  encoded  as  unique  random 
strings,  so  that  no  property  other  than  equality  can  be  directly  tested  by  the  adversary.  Five  oracles 
are  assumed  to  perform  operations  between  group  elements,  such  as  computing  the  group  action 
in  each  of  the  three  groups  Gi,  G2,  G t,  as  well  as  the  isomorphism  -0  :  G2  — ►  Gi,  and  the  bilinear 
pairing  e  :  Gi  x  G2  — >  G t-  The  opaque  encoding  of  the  elements  of  Gi  is  modeled  as  an  injective 
function  £1  :  Zp  — >  Hi,  where  Hi  C  {0,1}*,  which  maps  all  a  £  Zp  to  the  string  representation 
£1  (ga)  of  ga  £  Gi.  We  similarly  define  £2  :  Zp  — >■  H2  for  G2  and  :  Zp  — ►  H t  for  G t-  The  attacker 
A  communicates  with  the  oracles  using  the  ^-representations  of  the  group  elements  only. 

Theorem  5.1.  Let  A  be  an  algorithm  that  solves  the  q-SDH  problem  in  the  generic  group  model, 
making  a  total  of  at  most  qG  queries  to  the  oracles  computing  the  group  action  in  Gi,G2,G t,  the 
oracle  computing  the  isomorphism  ip,  and  the  oracle  computing  the  bilinear  pairing  e.  If  x  £  Z* 
and  £1,  £2;  f,T  are  chosen  at  random,  then  the  probability  e  that  A(p,  £i(l),  £2(1),  £2(2;),  •  •  •  ,  £2(2^)) 
outputs  (c,  ^i(A^))  with  c  £  Z*,  is  bounded  by 

e  <  (gc  +  g  +  2)2g  =  Qf  (qG)2q  +  q3 
P  V  P 

Proof.  Consider  an  algorithm  B  that  plays  the  following  game  with  A. 

B  maintains  three  lists  of  pairs  L\  =  {(Fgj,  £i,j)  :  i  =  0, .  ..,n  —  1},  L2  =  : 

i  =  0, , . . ,  T2  —  1},  Lt  =  ■  i  =  0, . . . ,  tt  —  1},  such  that,  at  step  r  in  the  game, 

T\  +  T2  +  tt  =  t  +  q  +  2.  The  Fip  and  F^i  are  polynomials  of  degree  <  q  in  Zp[x\,  and  the  Ft.i 
are  polynomials  of  degree  <  2 q  in  Zp[x\.  The  £1^,  £2 £,r,i  are  strings  in  {0,1}*.  The  lists  are 
initialized  at  step  r  =  0  by  taking  t\  =  1,  72  =  q  +  1,  tt  =  0,  and  posing  Fj.o  =  1,  and  Fz.i  =  xl 
for  i  £  {0, . . . ,  (/}.  The  corresponding  £1.0  and  ^2 4  are  set  to  arbitrary  distinct  strings  in  {0, 1}*. 

We  may  assume  that  A  only  makes  oracle  queries  on  strings  previously  obtained  form  B,  since 
B  can  make  them  arbitrarily  hard  to  guess.  We  note  that  B  can  determine  the  index  i  of  any  given 
string  £1  .j  in  L\  (resp.  £2 ,i  in  L2,  or  in  Lt),  breaking  ties  between  multiple  matches  arbitrarily. 
B  starts  the  game  by  providing  A  with  the  q  +  2  strings  £1,0,  £2,0,  •  •  • ,  £2 ,q-  Queries  go  as  follows. 

Group  action:  Given  a  multiply /divide  selection  bit  and  two  operands  with  0  <  i,  j  <  r\, 

we  compute  Tj)T1  <—  F\p  ±  F\j  £  Zp[x]  depending  on  whether  a  multiplication  or  a  division 
is  requested.  If  Fj,Tl  =  F\j  for  some  l<  T\,  we  set  Q)T,  <—  otherwise,  we  set  £i)Tl  to  a 
string  in  {0, 1}*  distinct  from  We  add  (_Fi)T1,  ^i,T1)  to  L\  and  give  £i>T1  to  A, 

then  increment  T\  by  one.  Group  action  queries  in  G2  and  G^  are  treated  similarly. 

Isomorphism:  Given  a  string  £2 ,i  with  0  <  i  <  T2,  we  let  F\  Tl  F%i  £  Zp[x\.  If  F\  T]  =  F\  \  for 
some  l  <  n,  we  set  ^ijTl  <—  otherwise,  we  set  £iiTl  to  a  string  in  {0,  l}*\{Ci,o,  •  •  • ,  ^i>n-i}. 
We  add  (_Fi)T1,£i)T1)  to  L\ ,  give  £ijT1  to  A,  and  increment  ti  by  one. 
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Pairing:  Given  two  operands  £i,i  and  £2 j  with  0  <  i  <  t\  and  0  <  j  <  r2,  we  compute  the  product 
FT,Tt  F\.i  ■  F2 j  G  Zp[x].  If  Ft,tt  =  Ft,i  for  some  l  <  tt,  we  set  £t,tt  £t,z;  otherwise,  we 
set  £t,tt  to  a  string  in  {0, 1}*  \  {£t,o>  •  •  • ,  We  add  (Ft,Tt,  £t,tt)  to  Lt ,  give  £t,tt  to 

A,  and  increment  tt  by  one. 

A  terminates  and  returns  a  pair  (c,  £  1^)  where  0  <  i  <  r\.  Let  F\j:  be  the  corresponding 
polynomial  in  the  list  L\.  In  order  to  exhibit  the  correctness  of  *4’s  answer  within  the  simulation 
framework,  B  computes  the  polynomial  Ft,*  =  F^  •  (F2,i  +  [c]F2,o)  =  F^  ■  (x  +  c).  Notice  that  if 
v4’s  answer  is  correct  then  necessarily 


Ft, *(x)  -1  =  0  (3) 

Indeed,  this  equality  corresponds  to  the  DDH  relation  “e(A,  g^g?)  =  e(<7i,  (72)”  where  A  denotes  the 
element  of  Oi  represented  by  £1  />.  Observe  that  since  the  constant  monomial  “1”  has  degree  0  and 
Ft,*  =  Fi,£  •  (x  +  c)  where  ( x  +  c )  has  degree  1,  the  above  relation  (3)  cannot  be  satisfied  identically 
in  Z p[x\  unless  F\  j:  has  degree  >  p  —  2.  We  know  that  the  degree  of  F\j  is  at  most  q,  therefore 
we  deduce  that  there  exists  a  value  of  x  for  which  Equation  (3)  does  not  hold.  Thus,  since  it  is  a 
non-trivial  polynomial  equation  of  degree  <  q  +  1,  it  admits  at  most  q  +  1  roots  in  Zp. 

At  this  point  B  chooses  a  random  x*  G  Zp.  The  simulation  provided  by  B  is  perfect  unless  the 

instantiation  x  <—  x*  creates  an  equality  relation  between  the  simulated  group  elements  that  was 

not  revealed  to  A ,  a  category  in  which  relation  (3)  belongs,  as  we  just  shown.  Thus,  the  success 
probability  of  A  is  bounded  by  the  probability  that  any  of  the  following  holds: 

1.  Fi,j(x*)  —  Fij(x*)  =  0  for  some  i,j  such  that  F,*  /  Fij, 

2.  F2)i(z*)  —  F2J(x*)  =  0  for  some  i,j  such  that  F2,i  /  F2,j, 

3.  Fx,i(x*)  —  Fx,j{x*)  =  0  for  some  i,j  such  that  Ft,,:  A  Ftj , 

4.  Fm(x*)  •  (x*  +  c)  —  1  =  0. 

Since  Fi  j  —  F\j  for  fixed  i  and  j  is  a  polynomial  of  degree  at  most  q,  it  vanishes  at  a  random  x*  G  Z p 
with  probability  at  most  q/p.  Similarly,  for  fixed  i  and  j,  the  second  case  occurs  with  probability 
<  q/p,  the  third  with  probability  <  2 q/p  (since  Ft,,  —  Ftj  has  degree  at  most  2 q),  and  the  fourth 
with  probability  <  (q  +  1  )/p.  By  summing  over  all  valid  pairs  (i,j)  in  each  case,  we  find  that  A 
wins  the  game  with  probability  e  <  (T^)  2  +  (' ^2)  ^  +  (TJ)  y  +  Since  n  +  r2  +  tt  <  qG  +  q  +  2, 
the  required  bound  follows:  e  <  (qG  +  q  +  2 )2(q/p)  =  0((qa)2(q/p)  +  q3/p).  □ 

Corollary  5.2.  Any  adversary  that  solves  the  q-SDH  problem  with  constant  probability  e  >  0  in 
generic  groups  of  order  p  such  that  q  <  o(typ)  requires  fi(y/ ep/q)  generic  group  operations. 

6  Conclusions 

We  presented  a  number  of  short  signature  schemes  based  on  the  g-SDH  assumption.  Our  main 
result  is  a  short  signature  which  is  fully  secure  without  using  the  random  oracle  model.  The 
signature  is  as  short  as  DSA  signatures,  but  is  provably  secure  in  the  standard  model.  We  also 
showed  that  the  scheme  supports  limited  message  recovery,  for  even  greater  compactness. 

These  constructions  are  possible  thanks  to  properties  of  the  g-SDH  assumption.  The  assumption 
can  be  viewed  as  a  discrete  logarithm  analogue  of  the  Strong  RSA  assumption.  We  believe  the 
g-SDH  assumption  is  a  useful  tool  for  constructing  cryptographic  systems  and  we  expect  to  see 
many  other  schemes  based  on  it.  For  example,  we  mention  a  new  group  signature  scheme  of  Boneh 
et  al.  [BBS04] . 
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Abstract 

We  study  the  problem  of  searching  on  data  that  is  encrypted  using  a  public  key  system. 
Consider  user  Bob  who  sends  email  to  user  Alice  encrypted  under  Alice’s  public  key.  An  email 
gateway  wants  to  test  whether  the  email  contains  the  keyword  “urgent”  so  that  it  could  route 
the  email  accordingly.  Alice,  on  the  other  hand  does  not  wish  to  give  the  gateway  the  ability  to 
decrypt  all  her  messages.  We  define  and  construct  a  mechanism  that  enables  Alice  to  provide  a 
key  to  the  gateway  that  enables  the  gateway  to  test  whether  the  word  “urgent”  is  a  keyword  in 
the  email  without  learning  anything  else  about  the  email.  We  refer  to  this  mechanism  as  Public 
Key  Encryption  with  keyword  Search.  As  another  example,  consider  a  mail  server  that  stores 
various  messages  publicly  encrypted  for  Alice  by  others.  Using  our  mechanism  Alice  can  send 
the  mail  server  a  key  that  will  enable  the  server  to  identify  all  messages  containing  some  specific 
keyword,  but  learn  nothing  else.  We  define  the  concept  of  public  key  encryption  with  keyword 
search  and  give  several  constructions. 


1  Introduction 

Suppose  user  Alice  wishes  to  read  her  email  on  a  number  of  devices:  laptop,  desktop,  pager,  etc. 
Alice’s  mail  gateway  is  supposed  to  route  email  to  the  appropriate  device  based  on  the  keywords 
in  the  email.  For  example,  when  Bob  sends  email  with  the  keyword  “urgent”  the  mail  is  routed  to 
Alice’s  pager.  When  Bob  sends  email  with  the  keyword  “lunch”  the  mail  is  routed  to  Alice’s  desktop 
for  reading  later.  One  expects  each  email  to  contain  a  small  number  of  keywords.  For  example, 
all  words  on  the  subject  line  as  well  as  the  sender’s  email  address  could  be  used  as  keywords.  The 
mobile  people  project  [24]  provides  this  email  processing  capability. 

Now,  suppose  Bob  sends  encrypted  email  to  Alice  using  Alice’s  public  key.  Both  the  contents  of 
the  email  and  the  keywords  are  encrypted.  In  this  case  the  mail  gateway  cannot  see  the  keywords 
and  hence  cannot  make  routing  decisions.  As  a  result,  the  mobile  people  project  is  unable  to  process 
secure  email  without  violating  user  privacy.  Our  goal  is  to  enable  Alice  to  give  the  gateway  the 
ability  to  test  whether  “urgent”  is  a  keyword  in  the  email,  but  the  gateway  should  learn  nothing 
else  about  the  email.  More  generally,  Alice  should  be  able  to  specify  a  few  keywords  that  the  mail 
gateway  can  search  for,  but  learn  nothing  else  about  incoming  mail.  We  give  precise  definitions  in 
section  2. 
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To  do  so,  Bob  encrypts  his  email  using  a  standard  public  key  system.  He  then  appends  to  the 
resulting  ciphertext  a  Public-Key  Encryption  with  keyword  Search  (PEKS)  of  each  keyword.  To 
send  a  message  M  with  keywords  W\ , . . . ,  Wm  Bob  sends 

EApub(M )  ||  PEKS(Apu6, W\)  ||  •••  ||  PEKS {Avub,Wm) 

Where  Apub  is  Alice’s  public  key.  The  point  of  this  form  of  encryption  is  that  Alice  can  give  the 
gateway  a  certain  trapdoor  Tw  that  enables  the  gateway  to  test  whether  one  of  the  keywords 
associated  with  the  message  is  equal  to  the  word  W  of  Alice’s  choice.  Given  PEKS(Apui,,  W')  and 
Tw  the  gateway  can  test  whether  W  =  W' .  If  W  ^  W'  the  gateway  learns  nothing  more  about  W' . 
Note  that  Alice  and  Bob  do  not  communicate  in  this  entire  process.  Bob  generates  the  searchable 
encryption  for  W'  just  given  Alice’s  public  key. 

In  some  cases,  it  is  instructive  to  view  the  email  gateway  as  an  IMAP  or  POP  email  server. 
The  server  stores  many  emails  and  each  email  contains  a  small  number  of  keywords.  As  before,  all 
these  emails  are  created  by  various  people  sending  mail  to  Alice  encrypted  using  her  public  key.  We 
want  to  enable  Alice  to  ask  queries  of  the  form:  do  any  of  the  messages  on  the  server  contain  the 
keyword  “urgent”?  Alice  would  do  this  by  giving  the  server  a  trapdoor  Tw ,  thus  enabling  the  server 
to  retrieve  emails  containing  the  keyword  W .  The  server  learns  nothing  else  about  the  emails. 

Related  work.  A  related  issue  deals  with  privacy  of  database  data.  There  are  two  different 
scenarios:  public  databases  and  private  databases,  and  the  solutions  for  each  are  different. 

Private  databases:  In  this  settings  a  user  wishes  to  upload  its  private  data  to  a  remote  database  and 
wishes  to  keep  the  data  private  from  the  remote  database  administrator.  Later,  the  user  must  be 
able  to  retrieve  from  the  remote  database  all  records  that  contain  a  particular  keyword.  Solutions 
to  this  problem  were  presented  in  the  early  1990’s  by  Ostrovsky  [26]  and  Ostrovsky  and  Goldreich 
[17]  and  more  recently  by  Song  at  al.  [28].  The  solution  of  Song,  at  al  [28]  requires  very  little 
communication  between  the  user  and  the  database  (proportional  to  the  security  parameter)  and 
only  one  round  of  interaction.  The  database  performs  work  that  is  linear  in  its  size  per  query. 
The  solution  of  [26,  17]  requires  poly-logarithmic  rounds  (in  the  size  of  the  database)  between 
the  user  and  the  database,  but  allows  the  database  to  do  only  poly-logarithmic  work  per  query. 
An  additional  privacy  requirement  that  might  be  appealing  in  some  scenarios  is  to  hide  from  the 
database  administrator  any  information  regarding  the  access  pattern,  i.e.  if  some  item  was  retrieved 
more  then  once,  some  item  was  not  retrieved  at  all,  etc.  The  work  of  [26,  17]  achieves  this  property 
as  well,  with  the  same  poly-logarithmic  cost1  per  query  both  for  the  database-user  interaction  and 
the  actual  database  work.  We  stress  that  both  the  constructions  of  [26,  17]  and  the  more  recent 
work  of  [10,  28,  16]  apply  only  to  the  private-key  setting  for  users  who  own  their  data  and  wish  to 
upload  it  to  a  third-party  database  that  they  do  not  trust. 

Public  Databases  Here  the  database  data  is  public  (such  as  stock  quotes)  but  the  user  is  unaware 
of  it  and  wishes  to  retrieve  some  data-item  or  search  for  some  data-item,  without  revealing  to  the 
database  administrator  which  item  it  is.  The  naive  solution  is  that  the  user  can  download  the 
entire  database.  Public  Information  Retrieval  (PIR)  protocols  allow  user  to  retrieve  data  from  a 
public  database  with  far  smaller  communication  then  just  downloading  the  entire  database.  PIR 
was  first  shown  to  be  possible  only  in  the  setting  where  there  are  many  copies  of  the  same  database 
and  none  of  the  copies  can  talk  to  each  other  [5].  PIR  was  shown  to  be  possible  for  a  single 
database  by  Kushilevitz  and  Ostrovsky  [22]  (using  homomorphic  encryption  scheme  of  [19]).  The 
communication  complexity  of  [22]  solution  (i.e.  the  number  of  bits  transmitted  between  the  user 

1The  poly-logarithmic  construction  of  [26,  17]  requires  large  constants,  which  makes  it  impractical;  however  their 
basic  O(yTi)  solution  was  recently  shown  to  be  applicable  for  some  practical  applications  [10]. 
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and  the  database)  is  0(ne),  where  n  is  the  size  of  the  database  and  e  >  0.  This  was  reduced  to 
poly-logarithmic  overhead  by  Cachin,  Micali,  and  Stadler  [4].  As  pointed  out  in  [22],  the  model  of 
PIR  can  be  extended  to  one-out-of-n  Oblivious  Transfer  and  keyword  searching  on  public  data,  and 
received  a  lot  of  additional  attention  in  the  literature  (see,  for  example,  [22,  8,  20,  9,  23,  25,  27]. 
We  stress  though  that  in  all  these  settings  the  database  is  public,  and  the  user  is  trying  to  retrieve 
or  find  certain  items  without  revealing  to  the  database  administrator  what  it  is  searching  for.  In 
the  setting  of  a  single  public  database,  it  can  be  shown  that  the  database  must  always  perform 
work  which  is  at  least  linear  in  the  size  of  the  database. 

Our  problem  does  not  fit  either  of  the  two  models  mentioned  above.  Unlike  the  private-key 
setting,  data  collected  by  the  mail-server  is  from  third  parties,  and  can  not  be  “organized”  by  the 
user  in  any  convenient  way.  Unlike  the  publicly  available  database,  the  data  is  not  public,  and 
hence  the  PIR  solutions  do  not  apply. 

We  point  out  that  in  practical  applications,  due  to  the  computation  cost  of  public  key  encryption, 
our  constructions  are  applicable  to  searching  on  a  small  number  of  keywords  rather  than  an  entire 
file.  Recently,  Waters  et  al.  [30]  showed  that  public  key  encryption  with  keyword  search  can  be 
used  to  build  an  encrypted  and  searchable  audit  log.  Other  methods  for  searching  on  encrypted 
data  are  described  in  [16,  12]. 

2  Public  key  encryption  with  searching:  definitions 

Throughout  the  paper  we  use  the  term  negligible  function  to  refer  to  a  function  /  :  M  — ►  [0, 1]  where 
/(s)  <  1  /g(s)  for  any  polynomial  g  and  sufficiently  large  s. 

We  start  by  precisely  defining  what  is  a  secure  Public  Key  Encryption  with  keyword  Search 
(PEKS)  scheme.  Here  “public-key”  refers  to  the  fact  that  ciphertexts  are  created  by  various  people 
using  Alice’s  public  key.  Suppose  user  Bob  is  about  to  send  an  encrypted  email  to  Alice  with 
keywords  W\, . . . ,  (e.g.,  words  in  the  subject  line  and  the  sender’s  address  could  be  used  as 

keywords,  so  that  k  is  relatively  small).  Bob  sends  the  following  message: 

[EApub[msg\,  PEKS(Apu6,  W\), ....  PEKS(Apub,  W]f)\  (1) 

where  Apub  is  Alice’s  public  key,  msg  is  the  email  body,  and  PEKS  is  an  algorithm  with  properties 
discussed  below.  The  PEKS  values  do  not  reveal  any  information  about  the  message,  but  enable 
searching  for  specific  keywords.  For  the  rest  of  the  paper,  we  use  as  our  sample  application  a  mail 
server  that  stores  all  incoming  email. 

Our  goal  is  to  enable  Alice  to  send  a  short  secret  key  Tw  to  the  mail  server  that  will  enable 
the  server  to  locate  all  messages  containing  the  keyword  W,  but  learn  nothing  else.  Alice  produces 
this  trapdoor  Tw  using  her  private  key.  The  server  simply  sends  the  relevant  emails  back  to  Alice. 
We  call  such  a  system  non-interactive  public  key  encryption  with  keyword  search ,  or  as  a  shorthand 
“searchable  public-key  encryption” . 

Definition  2.1.  A  non-interactive  public  key  encryption  with  keyword  search  (we  sometimes  ab¬ 
breviate  it  as  “searchable  encryption” )  scheme  consists  of  the  following  polynomial  time  randomized 
algorithms: 

1.  KeyGen(s):  Takes  a  security  parameter,  s,  and  generates  a  public/private  key  pair  Apub,  Apriv. 

2.  PEKS(Apu(),  IT):  for  a  public  key  Apub  and  a  word  W,  produces  a  searchable  encryption  of  W. 

3.  Trapdoor(AprjP,  W):  given  Alice’s  private  key  and  a  word  W  produces  a  trapdoor  Tw. 

4.  Test(Apub,  S ,  Tw):  given  Alice’s  public  key,  a  searchable  encryption  S  =  PEKS(Apu6,  W'),  and 
a  trapdoor  Tw  =  Trapdoor(ApriP,  IT),  outputs  ‘yes’  if  W  =  W'  and  ‘no’  otherwise. 
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Alice  runs  the  KeyGen  algorithm  to  generate  her  public/private  key  pair.  She  uses  Trapdoor 
to  generate  trapdoors  Tw  for  any  keywords  W  that  she  wants  the  mail  server  or  mail  gateway  to 
search  for.  The  mail  server  uses  the  given  trapdoors  as  input  to  the  TestQ  algorithm  to  determine 
whether  a  given  email  contains  one  of  the  keywords  W  specified  by  Alice. 

Next,  we  define  security  for  a  PEKS  in  the  sense  of  semantic-security.  We  need  to  ensure  that  an 
PEKS(Apui),  W)  does  not  reveal  any  information  about  W  unless  Tw  is  available.  We  define  security 
against  an  active  attacker  who  is  able  to  obtain  trapdoors  Tw  for  any  W  of  his  choice.  Even  under 
such  attack  the  attacker  should  not  be  able  to  distinguish  an  encryption  of  a  keyword  Wo  from  an 
encryption  of  a  keyword  W\  for  which  he  did  not  obtain  the  trapdoor.  Formally,  we  define  security 
against  an  active  attacker  A  using  the  following  game  between  a  challenger  and  the  attacker  (the 
security  parameter  s  is  given  to  both  players  as  input). 

PEKS  Security  game: 

1.  The  challenger  runs  the  KeyGen  (s)  algorithm  to  generate  Apub  and  Apriv.  It  gives  Apub  to 
the  attacker. 

2.  The  attacker  can  adaptively  ask  the  challenger  for  the  trapdoor  Tw  for  any  keyword 
W  G  {0, 1}*  of  his  choice. 

3.  At  some  point,  the  attacker  A  sends  the  challenger  two  words  Wo,  W\  on  which  it  wishes 
to  be  challenged.  The  only  restriction  is  that  the  attacker  did  not  previously  ask  for  the 
trapdoors  T\y0  or  T\y1-  The  challenger  picks  a  random  b  G  {0, 1}  and  gives  the  attacker 
C  =  PEKS(Apu6,  Wb).  We  refer  to  C  as  the  challenge  PEKS. 

4.  The  attacker  can  continue  to  ask  for  trapdoors  Tw  for  any  keyword  W  of  his  choice  as 
long  as  W  +  W0,  W\ . 

5.  Eventually,  the  attacker  A  outputs  b'  G  {0, 1}  and  wins  the  game  if  b  =  b' . 

In  other  words,  the  attacker  wins  the  game  if  he  can  correctly  guess  whether  he  was  given  the 
PEKS  for  Wo  or  W\ .  We  define  A’s  advantage  in  breaking  the  PEKS  as 

Adv^(s)  =  |  Pr[6  =  b']  - 

Definition  2.2.  We  say  that  a  PEKS  is  semantically  secure  against  an  adaptive  chosen  keyword 
attack  if  for  any  polynomial  time  attacker  A  we  have  that  Adv_4(s)  is  a  negligible  function. 

Chosen  Ciphertext  Security.  We  note  that  Definition  2.2  ensures  that  the  construction  given 
in  Eq.  (1)  is  semantically  secure  whenever  the  public  key  encryption  system  E, \pub  is  semantically 
secure.  However,  as  is,  the  construction  is  not  chosen  ciphertext  secure.  Indeed,  a  chosen  cipher- 
text  attacker  can  break  semantic  security  by  reordering  the  keywords  in  Eq.  (1)  and  submitting 
the  resulting  ciphertext  for  decryption.  A  standard  technique  can  make  this  construction  chosen 
ciphertext  secure  using  the  methods  of  [7] .  We  defer  this  to  the  full  version  of  the  paper. 

2.1  PEKS  implies  Identity  Based  Encryption 

Public  key  encryption  with  keyword  search  is  related  to  Identity  Based  Encryption  (IBE)  [29,  2]. 
Constructing  a  secure  PEKS  appears  to  be  a  harder  problem  than  constructing  an  IBE.  Indeed,  the 
following  lemma  shows  that  PEKS  implies  Identity  Based  Encryption.  The  converse  is  probably 
false.  Security  notions  for  IBE,  and  in  particular  chosen  ciphertext  secure  IBE  (IND-ID-CCA),  are 
defined  in  [2]. 
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Lemma  2.3.  A  non-interactive  searchable  encryption  scheme  (PEKS,)  that  is  semantically  secure 
against  an  adaptive  chosen  keyword  attack  gives  rise  to  a  chosen  ciphertext  secure  IBE  system 
(IND-ID-CCA  ). 

Proof  sketch:  Given  a  PEKS  (KeyGen,  PEKS,  Trapdoor,  Test)  the  IBE  system  is  as  follows: 

1.  Setup:  Run  the  PEKS  KeyGen  algorithm  to  generate  Apub/ Apriv.  The  IBE  system  parameters 
are  Apub.  The  master-key  is  Apriv. 

2.  KeyGen:  The  IBE  private  key  associated  with  a  public  key  X  e  {0, 1}*  is 

dx  =  [Trapdoor(Apri„,  X||0),  Trapdoor(Aprip,  A'||l)]  , 
where  ||  denotes  concatenation. 

3.  Encrypt:  Encrypt  a  bit  b  €  {0, 1}  using  a  public  key  X  E  {0, 1}*  as:  CT  =  PEKS(Apu(),  X||6). 

4.  Decrypt:  To  decrypt  CT  =  PEKS(Apub,  X||6)  using  the  private  key  d\  =  (do,di). 

Output  ‘0’  if  Test(Apu6,  CT,  do)  =  ‘yes’  and  output  ‘1’  if  Test(Apui),  CT,  di)  =  ‘yes’ 

One  can  show  that  the  resulting  system  is  IND-ID-CCA  assuming  the  PEKS  is  semantically  secure 
against  an  adaptive  chosen  message  attack.  □ 

This  shows  that  building  non-interactive  public-key  searchable  encryption  is  at  least  as  hard  as 
building  an  IBE  system.  One  might  be  tempted  to  prove  the  converse  (i.e.,  IBE  implies  PEKS)  by 
defining 


PEKS(Aput,IU)  =Ew[0k]  (2) 

i.e.  encrypt  a  string  of  k  zeros  with  the  IBE  public  key  W  £  {0, 1}*.  The  Test  algorithm  attempts  to 
decrypt  Ew[ 0]  and  checks  that  the  resulting  plaintext  is  0k.  Unfortunately,  this  does  not  necessarily 
give  a  secure  searchable  encryption  scheme.  The  problem  is  that  the  ciphertext  CT  could  expose  the 
public  key  (W)  used  to  create  CT.  Generally,  an  encryption  scheme  need  not  hide  the  public  key 
that  was  used  to  create  a  given  ciphertext.  But  this  property  is  essential  for  the  PEKS  construction 
given  in  (2).  We  note  that  public  key  privacy  was  previously  studied  by  Bellare  et  al.  [1].  The 
construction  in  (2)  requires  an  IBE  system  that  is  public-key  private. 

Generally,  it  appears  that  constructing  a  searchable  public-key  encryption  is  a  harder  problem 
than  constructing  an  IBE  scheme.  Nevertheless,  our  first  PEKS  construction  is  based  on  a  recent 
construction  for  an  IBE  system.  We  are  able  to  prove  security  by  exploiting  extra  properties  of 
this  system. 

3  Constructions 

We  give  two  constructions  for  public-key  searchable  encryption:  (1)  an  efficient  system  based  on 
a  variant  of  the  Decision  Diffie-Hellman  assumption  (assuming  a  random  oracle)  and  (2)  a  limited 
system  based  on  general  trapdoor  permutations  (without  assuming  the  random  oracle),  but  less 
efficient. 
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3.1  Construction  using  bilinear  maps 

Our  first  construction  is  based  on  a  variant  of  the  Computational  Diffie-Hellman  problem.  Boneh 
and  Franklin  [2]  recently  used  bilinear  maps  on  elliptic  curves  to  build  an  efficient  IBE  system. 
Abstractly,  they  use  two  groups  Gu,G2  of  prime  order  p  and  a  bilinear  map  e  :  G\  x  G\  — >  G2 
between  them.  The  map  satisfies  the  following  properties: 

1.  Computable:  given  g,  h  £  G 1  there  is  a  polynomial  time  algorithms  to  compute  e(g ,  h )  £  G2. 

2.  Bilinear:  for  any  integers  x,y  £  [1  ,p\  we  have  e(gx,gy)  =  e(g,g)xy 

3.  Non-degenerate:  if  g  is  a  generator  of  G\  then  e(g,g)  is  a  generator  of  G 2. 

The  size  of  G 1,  G-2  is  determined  by  the  security  parameter. 

We  build  a  non-interactive  searchable  encryption  scheme  from  such  a  bilinear  map.  The  con¬ 
struction  is  based  on  [2].  We  will  need  hash  functions  H\  :  {0, 1}*  — ■>  G\  and  H2  :  G2  — »  {0,  l}logp. 
Our  PEKS  works  as  follows: 

•  KeyGen:  The  input  security  parameter  determines  the  size,  p,  of  the  groups  G 1  and  G*2.  The 
algorithm  picks  a  random  a  £  Z*  and  a  generator  g  of  G\.  It  outputs  Apub  =  [g,h  =  ga]  and 

A  =  ry 

•  PEKS(Apu(),  IF):  First  compute  t  =  e(H\(W),  hr)  £  G2  for  a  random  r  £  Z*. 

Output  PEKS(Apu6,  IF)  =  [ gr ,  H2(t)\. 

•  Trapdoor(Apri„,  IF):  output  Tw  =  H\(W)a  £  Gi. 

•  Test{Apub,S,Tw):  let  5=  [A,  B].  Test  if  H2(e(Tw,A))  =  B. 

If  so,  output  ‘yes’;  if  nob  output  ‘no’. 

We  prove  that  this  system  is  a  non-interactive  searchable  encryption  scheme  semantically  secure 
against  a  chosen  keyword  attack  in  the  random  oracle  model.  The  proof  of  security  relies  on  the 
difficulty  of  the  Bilinear  Diffie-Hellman  problem  (BDH)  [2,  21], 

Bilinear  Diffie-Hellman  Problem  (BDH):  Fix  a  generator  g  of  G \ .  The  BDH  problem  is  as 
follows:  given  g,ga,gb,gc  £  G\  as  input,  compute  e(g,g)abc  £  G2.  We  say  that  BDH  is  intractable 
if  all  polynomial  time  algorithms  have  a  negligible  advantage  in  solving  BDH. 

We  note  that  the  Boneh-Franklin  IBE  system  [2]  relies  on  the  same  intractability  assumption 
for  security.  The  security  of  our  PEKS  is  proved  in  the  following  theorem.  The  proof  is  set  in  the 
random  oracle  model.  Indeed,  it  is  currently  an  open  problem  to  build  a  secure  IBE,  and  hence  a 
PEKS,  without  the  random  oracle  model. 

Theorem  3.1.  The  non-interactive  searchable  encryption  scheme  (PEKS)  above  is  semantically 
secure  against  a  chosen  keyword  attack  in  the  random  oracle  model  assuming  BDH  is  intractable. 

Proof  :  Suppose  A  is  an  attack  algorithm  that  has  advantage  e  in  breaking  the  PEKS.  Suppose  A 
makes  at  most  qH2  hash  function  queries  to  H2  and  at  most  qT  trapdoor  queries  (we  assume  qT  and 
qHr>  are  positive).  We  construct  an  algorithm  B  that  solves  the  BDH  problem  with  probability  at 
least  e'  =  e/(eqTqH2),  where  e  is  the  base  of  the  natural  logarithm.  Algorithm  £>’ s  running  time  is 
approximately  the  same  as  A’s.  Hence,  if  the  BDH  assumption  holds  in  G 1  then  e/  is  a  negligible 
function  and  consequently  e  must  be  a  negligible  function  in  the  security  parameter. 

Let  g  be  a  generator  of  G\.  Algorithm  B  is  given  g ,  u\  =  ga,  U2  =  g^ ,us  =  g1  £  G\.  Its  goal  is 
to  output  v  =  e(g,g)a^'y  £  G2-  Algorithm  B  simulates  the  challenger  and  interacts  with  forger  A 
as  follows: 
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KeyGen.  Algorithm  B  starts  by  giving  A  the  public  key  Apub  =  [g,ui\. 


Hi,  H 2- queries.  At  any  time  algorithm  A  can  query  the  random  oracles  H \  or  H2.  To  respond  to 
H 1  queries  algorithm  B  maintains  a  list  of  tuples  (Wj,  hj,aj,  Cj)  called  the  L/i-hst.  The  list  is 
initially  empty.  When  A  queries  the  random  oracle  H\  at  a  point  Wj  G  {0, 1}*,  algorithm  B 
responds  as  follows: 

1.  If  the  query  Wj  already  appears  on  the  L/i-list  in  a  tuple  (Wj,  hi,  Oj ,  Cj)  then  algorithm  B 
responds  with  H\(Wt)  =  hi  G  G\. 

2.  Otherwise,  B  generates  a  random  coin  Cj  G  {0, 1}  so  that  Pr[cj  =  0]  =  l/(gT  +  1). 

3.  Algorithm  B  picks  a  random  a,  G  Zp. 

If  Cj  =  0,  £>  computes  hi  *—  U2  ■  gai  G  Gi. 

If  Cj  =  1,  £>  computes  hi  <—  gai  G  Gj . 

4.  Algorithm  £>  adds  the  tuple  ( Wj,  /ij,  aj,  Cj)  to  the  iLi-list  and  responds  to  A  by  setting 
tfi(Wj)  =  hi-  Note  that  either  way  hi  is  uniform  in  G±  and  is  independent  of  A’s  current 
view  as  required. 

Similarly,  at  any  time  A  can  issue  a  query  to  H2.  Algorithm  B  responds  to  a  query  for  H2(t) 
by  picking  a  new  random  value  V  G  {0,  l}logp  for  each  new  t  and  setting  H2(t)  =  V.  In 

addition,  B  keeps  track  of  all  H2  queries  by  adding  the  pair  (t,  V)  to  an  H2- list.  The  i^-list 

is  initially  empty. 

Trapdoor  queries.  When  A  issues  a  query  for  the  trapdoor  corresponding  to  the  word  Wj  algo¬ 
rithm  B  responds  as  follows: 

1.  Algorithm  B  runs  the  above  algorithm  for  responding  to  H i-queries  to  obtain  an  hi  G  G\ 
such  that  H\{Wi)  =  hi.  Let  (Wj, /tj,  aj,  Cj)  be  the  corresponding  tuple  on  the  H i-list.  If 
Cj  =  0  then  B  reports  failure  and  terminates. 

2.  Otherwise,  we  know  Cj  =  1  and  hence  hi  =  gai  G  G\ .  Define  Tj  =  ua{1 .  Observe  that 
Tj  =  H(Wi)a  and  therefore  Tj  is  the  correct  trapdoor  for  the  keyword  Wj  under  the 
public  key  Apub  =  [g,ui\.  Algorithm  B  gives  Tj  to  algorithm  A. 

Challenge.  Eventually  algorithm  A  produces  a  pair  of  keywords  Wo  and  Wi  that  it  wishes  to  be 
challenged  on.  Algorithm  B  generates  the  challenge  PEKS  as  follows: 

1.  Algorithm  B  runs  the  above  algorithm  for  responding  to  LT -queries  twice  to  obtain  a 
ho,  h±  G  G 1  such  that  H\(Wq)  =  ho  and  H\(W\)  =  h\.  For  i  =  0, 1  let  (Wj, /ij,  aj,  Cj)  be 
the  corresponding  tuples  on  the  TTi-list .  If  both  Co  =  1  and  ci  =  1  then  B  reports  failure 
and  terminates. 

2.  We  know  that  at  least  one  of  co,  ci  is  equal  to  0.  Algorithm  B  randomly  picks  a  b  G  {0, 1} 
such  that  ci,  =  0  (if  only  one  cj,  is  equal  to  0  then  no  randomness  is  needed  since  there 
is  only  one  choice). 

3.  Algorithm  B  responds  with  the  challenge  PEKS  C  =  [rt3,  J ]  for  a  random  J  G  {0,  l}logP. 
Note  that  this  challenge  implicitly  defines  H2(e(Hi(Wb),uJ))  =  J.  In  other  words, 

J  =  H2(e(Hi(Wb),uJ))  =  H2(e(u2gab,g a7))  =  H2(e(g,g)a^+a^) 

With  this  definition,  C  is  a  valid  PEKS  for  Wf,  as  required. 

More  trapdoor  queries.  A  can  continue  to  issue  trapdoor  queries  for  keywords  Wj  where  the 
only  restriction  is  that  Wj  A  Wj ,  Wi.  Algorithm  B  responds  to  these  queries  as  before. 
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Output.  Eventually,  A  outputs  its  guess  b'  £  {0, 1}  indicating  whether  the  challenge  C  is  the  result 
of  PEKS(Apui),  Wq)  or  PEKS(Apu6,  W\ ) .  At  this  point,  algorithm  B  picks  a  random  pair  (t,  V) 
from  the  //2-list  and  outputs  t/ e{ui,uo)ab  as  its  guess  for  e(g,g)°1^1,  where  a&  is  the  value 
used  in  the  Challenge  step.  The  reason  this  works  is  that,  as  we  will  show,  A  must  have  issued 
a  query  for  either  H2(e(H\(Wo),  uj))  or  H2(e(H\{W\),  «/)).  Therefore,  with  probability  1/2 
the  //2-list  contains  a  pair  whose  left  hand  side  is  t  =  e(Hi(Wb),uJ )  =  e(g ,  g)ai^+ab\  If  B 
picks  this  pair  (t,V)  from  the  //2-list  then  t/ e{u\,uo)ab  =  e(g, g)0^1  as  required. 

This  completes  the  description  of  algorithm  B.  It  remains  to  show  that  B  correctly  outputs 
e(g,g)a^1  with  probability  at  least  e' .  To  do  so,  we  first  analyze  the  probability  that  B  does 
not  abort  during  the  simulation.  We  define  two  events: 

£\ :  B  does  not  abort  as  a  result  of  any  of  A’s  trapdoor  queries. 

£ 2 •  B  does  not  abort  during  the  challenge  phase. 

We  first  argue  as  in  [6]  that  both  events  £\  and  £2  occur  with  sufficiently  high  probability. 

Claim  1:  The  probability  that  algorithm  B  does  not  abort  as  a  result  of  *4’s  trapdoor  queries  is 
at  least  1/e.  Hence,  Pr[£i]  >l/e. 

Proof.  Without  loss  of  generality  we  assume  that  A  does  not  ask  for  the  trapdoor  of  the  same 
keyword  twice.  The  probability  that  a  trapdoor  query  causes  B  to  abort  is  1  /(qT  +  1).  To  see  this, 
let  Wi  be  A’s  i’th  trapdoor  query  and  let  (H7,:,  hi ,  at,  a)  be  the  corresponding  tuple  on  the  H i-list. 
Prior  to  issuing  the  query,  the  bit  ct  is  independent  of  A’s  view  —  the  only  value  that  could  be 
given  to  A  that  depends  on  c*  is  H(W{),  but  the  distribution  on  H(Wj)  is  the  same  whether  a  =  0 
or  a  =  1.  Therefore,  the  probability  that  this  query  causes  B  to  abort  is  at  most  1  /(qT  +  1). 
Since  A  makes  at  most  qT  trapdoor  queries  the  probability  that  B  does  not  abort  as  a  result  of  all 
trapdoor  queries  is  at  least  (1  —  1  /(qT  +  l))qT  >  1/e.  □ 

Claim  2:  The  probability  that  algorithm  B  does  not  abort  during  the  challenge  phase  is  at  least 
1  /qT.  Hence,  Prf/b]  >  1  /qT- 

Proof.  Algorithm  B  will  abort  during  the  challenge  phase  if  A  is  able  to  produce  Wo,  W\  with  the 
following  property:  Co  =  c\  =  1  where  for  i  =  0, 1  the  tuple  (Wi,  hi,  cii,  cf)  is  the  tuple  on  the  H i-list 
corresponding  to  Wt .  Since  A  has  not  queried  for  the  trapdoor  for  Wo,  W\  we  have  that  both  cq,  c\ 
are  independent  of  A’s  current  view.  Therefore,  since  Pr[Q  =  0]  =1/ (qTP  1)  for  /  =  0, 1,  and  the  two 
values  are  independent  of  one  another,  we  have  that  Pr[co  =  c\  =  1]  =  (1  —  l/(qT  +  l))2  <  1  —  1  /qT. 
Hence,  the  probability  that  B  does  not  abort  is  at  least  1  / qr ■  □ 

Observe  that  since  A  can  never  issue  a  trapdoor  query  for  the  challenge  keywords  Wo,  W\  the 
two  events  £\  and  £2  are  independent.  Therefore,  Pr[£i  A  £2]  >  l/(eqT). 

To  complete  the  proof  of  Theorem  3.1  it  remains  to  show  that  B  outputs  the  solution  to  the 
given  BDH  instance  with  probability  at  least  e/qH2  ■  To  do  we  show  that  during  the  simulation  A 
issues  a  query  for  //2(e(//i(H/f)),  uj))  with  probability  at  least  e. 

Claim  3:  Suppose  that  in  a  real  attack  game  A  is  given  the  public  key  [g,  u\]  and  A  asks  to  be 
challenged  on  words  Wo  and  W\.  In  response,  A  is  given  a  challenge  C  =  [gr,J].  Then,  in  the 
real  attack  game  A  issues  an  H2  query  for  either  H2(e(Hi(Wo),u\))  or  H2(e(Hi(Wi),u\))  with 
probability  at  least  2e. 

Proof.  Let  £3  be  the  event  that  in  the  real  attack  A  does  not  issue  a  query  for  either  one  of 
H2(e(Hi(Wo),url))  and  H2(e(Hi(W\),  u^)).  Then,  when  £3  occurs  we  know  that  the  bit  b  £  {0, 1} 
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indicating  whether  C  is  a  PEKS  of  Wq  or  W\  is  independent  of  A’s  view.  Therefore,  A’s  output  b' 
will  satisfy  b  =  b'  with  probability  at  most  2 .  By  definition  of  A.  we  know  that  in  the  real  attack 
|  Pr[6  =  b'}  —  1/2 1  >  e.  We  show  that  these  two  facts  imply  that  Pr [ — '£*3]  >  2e.  To  do  so,  we  first 
derive  simple  upper  and  lower  bounds  on  Pr[6  =  b']: 

Pr  [b  =  b']  =  Pr[6  =  6'I^Pr^s] +  Pr[6  =  6'h^Prh^] 

<  Pr [b  =  b'\£ 3]  Pr[f3]  +  Pr[-.f3]  =  \  Pr[f3]  +  Pi'Ks] 

=  Wt*™* 

Pr[6  =  b ']  >  Pr[6  =  b'\£3\  Pr[£3]  =  ^  Pr[£3]  =  \~\  Prh^3]- 

It  follows  that  e  <  |  Pr[6  =  b']  —  1/2|  <  |Pr[-i£3].  Therefore,  in  the  real  attack,  Pr[— i£3]  >  2e  as 
required.  □ 

Now,  assuming  B  does  not  abort,  we  know  that  B  simulates  a  real  attack  game  perfectly  up  to 
the  moment  when  A  issues  a  query  for  either  H2(e(Hi(Wo),  uj))  or  H2(e(H\(W\),  uj)).  Therefore, 
by  Claim  3,  by  the  end  of  the  simulation  A  will  have  issued  a  query  for  either  H2(e(Hi(Wo),  uj))  or 
H2(e(Hi(Wi),  u]))  with  probability  at  least  2e.  It  follows  that  A  issues  a  query  for  H2(e(Hi(Wb),  u'()) 
with  probability  at  least  e.  Consequently,  the  value  e(Hi(Wb),  uj)  =  e(gl3+ab,  g)ai  will  appear  on 
the  left  hand  side  of  some  pair  in  the  H2- list.  Algorithm  B  will  choose  the  correct  pair  with  proba¬ 
bility  at  least  1  /qH2  and  therefore,  assuming  B  does  not  abort  during  the  simulation,  it  will  produce 
the  correct  answer  with  probability  at  least  e/qH2.  Since  B  does  not  abort  with  probability  at  least 
1  /(eqT)  we  see  that  B's  success  probability  overall  is  at  least  e/(eqTqH2 )  as  required.  □ 

3.2  A  limited  construction  using  any  trapdoor  permutation 

Our  second  PEKS  construction  is  based  on  general  trapdoor  permutations,  assuming  that  the  total 
number  of  keywords  that  the  user  wishes  to  search  for  is  bounded  by  some  polynomial  function 
in  the  security  parameter.  (As  a  first  step  in  our  construction,  we  will  make  an  even  stronger 
assumption  that  the  total  number  of  words  S  C  {0, 1}*  in  the  dictionary  is  also  bounded  by  a 
polynomial  function,  we  will  later  show  how  to  remove  this  additional  assumption.)  We  will  also 
need  a  family  of  semantically-secure  encryptions  where  given  a  ciphertext  it  is  computationally  hard 
to  say  which  public-key  this  ciphertext  is  associated  with.  This  notion  was  formalized  by  Bellare 
et  al.  [1].  We  say  that  a  public-key  system  that  has  this  property  is  source-indistinguishable. 
More  precisely,  source-indistinguishability  for  an  encryption  scheme  (G,  E ,  D )  is  defined  using  the 
following  game  between  a  challenger  and  an  attacker  A  (here  G  is  the  key  generation  algorithm, 
and  E/D  are  encryption/decryption  algorithms).  The  security  parameter  s  is  given  to  both  players. 
Source  Indistinguishability  security  game: 

1.  The  challenger  runs  algorithm  G(s)  two  times  to  generate  two  public/private  key  pairs 
(PKq,  Privo)  and  {PK\,Priv\). 

2.  The  challenger  picks  a  random  M  £  {0, 1}S  and  a  random  b  £  {0, 1}  and  computes  an 
encryption  C  =  P A;, ( M ) .  The  challenger  gives  ( M,C )  to  the  attacker. 

3.  The  attacker  outputs  b'  and  wins  the  game  if  b  =  b' . 

In  other  words,  the  attacker  wins  if  he  correctly  guesses  whether  he  was  given  the  encryption 
of  M  under  PKq  or  under  PK\ .  We  define  A’s  advantage  in  winning  the  game  as: 

AdvS IA(s)  =  |  Pr[6  =  b']  -  ^ 
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Definition  3.2.  We  say  that  a  public-key  encryption  scheme  is  source  indistinguishable  if  for  any 
polynomial  time  attacker  A  we  have  that  AdvSI.g(s)  is  a  negligible  function. 

We  note  that  Bellare  et  al.  [1]  define  a  stronger  notion  of  source  indistinguishability  than  the 
one  above  by  allowing  the  adversary  to  choose  the  challenge  message  M .  For  our  purposes,  giving 
the  adversary  an  encryption  of  a  random  message  is  sufficient. 

Source  indistinguishability  can  be  attained  from  any  trapdoor  permutation  family,  where  for  a 
given  security  parameter  all  permutations  in  the  family  are  defined  over  the  same  domain.  Such  a 
family  can  be  constructed  from  any  family  of  trapdoor  permutations  as  described  in  [1],  Then  to 
encrypt  a  bit  6  we  pick  a  random  x,  and  output  [f(x),  GL(x)  0  6]  where  GL  is  the  Goldreich-Levin 
hard-core  bit  [19].  We  therefore  obtain  the  following  lemma: 

Lemma  3.3.  Given  any  trapdoor  permutation  family  we  can  construct  a  semantically  secure  source 
indistinguishable  encryption  scheme. 

More  constructions  are  given  in  [1],  We  note  that  source  indistinguishability  is  an  orthogonal 
property  to  semantic  security.  One  can  build  a  semantically  secure  system  that  is  not  source 
indistinguishable  (by  embedding  the  public  key  in  every  ciphertext).  Conversely,  one  can  build 
a  source  indistinguishable  system  that  is  not  semantically  secure  (by  embedding  the  plaintext  in 
every  ciphertext). 

A  simple  PEKS  from  trapdoor  permutations.  When  the  keyword  family  £  is  of  polynomial 
size  (in  the  security  parameter)  it  is  easy  to  construct  searchable  encryption  from  any  source- 
indistinguishable  public- key  system  (G,  E ,  D).  We  let  s  be  the  security  parameter  for  the  scheme. 

•  KeyGen:  For  each  W  G  E  run  G(s)  to  generate  a  new  public/private  key  pair  PKW  /  Privw 
for  the  source-indistinguishable  encryption  scheme.  The  PEKS  public  key  is 

Apub  =  {PKW  |  W  G  E}.  The  private  key  is  Apriv  =  {Privw  \  W  G  £}. 

•  PEKS(Apu(),  W ):  Pick  a  random  M  G  {0, 1}S  and  output  PEKS(Apu6,  W)  =  ( M ,  E[PKW,  M]), 
i.e.  encrypt  M  using  the  public  key  PKW. 

•  Trapdoor (Apriv,W):  The  trapdoor  for  word  W  is  simply  Tw  =  Privw. 

•  Test(Apub,  S,  Tw ):  Test  if  the  decryption  D[TW,  5]  =  0s.  Output  ‘yes’  if  so  and  ‘no’  otherwise. 

Note  that  the  dictionary  must  be  of  polynomial  size  (in  s)  so  that  the  public  and  private  keys  are 
of  polynomial  size  (in  s). 

This  construction  gives  a  semantically  secure  PEKS  as  stated  in  the  following  simple  theorem. 
Semantically  secure  PEKS  is  defined  as  in  Definition  2.2  except  that  the  adversary  is  not  allowed 
to  make  chosen  keyword  queries. 

Theorem  3.4.  The  PEKS  scheme  above  is  semantically  secure  assuming  the  underlying  public  key 
encryption  scheme  (G,  E,  D )  is  source-indistinguishable. 

Proof  sketch:  Let  E  =  {Wi, . . . ,  IF*,}  be  the  keyword  dictionary.  Suppose  we  have  a  PEKS 
attacker  A  for  which  Adv_4(s)  >  e(s).  We  build  an  attacker  B  that  breaks  the  source  indistin¬ 
guishability  of  (■ G,E,D )  where  AdvSIg(s)  >  e{s)/k2. 

The  reduction  is  immediate:  B  is  given  two  public  keys  PKq.  PK\  and  a  pair  (M,C)  where 
M  is  random  in  {0, 1}S  and  C  =  PKb(M )  for  6  G  {0, 1}.  Algorithm  B  generates  k  —  2  additional 
public/private  keys  using  G(s).  It  creates  Apub  as  a  list  of  all  k  public  keys  with  PKq,PKi 
embedded  in  a  random  location  in  the  list.  Let  Wi ,  Wj  be  the  words  associated  with  the  public 
keys  PK(j .  PK \ .  B  sends  Apub  to  A  who  then  responds  with  two  words  Wk,Wi  G  E  on  which  A 
wishes  to  be  challenged.  If  {i.  j}  A  algorithm  B  reports  failure  and  aborts.  Otherwise,  B 
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sends  the  challenge  (M,  C )  to  A  who  then  responds  with  a  G  {0, 1}.  Algorithm  B  outputs  b'  as 
its  response  to  the  source  indistinguishability  challenge.  We  have  that  b  =  b'  if  algorithm  B  did 
not  abort  and  A’s  response  was  correct.  This  happens  with  probability  at  least  \  +  e/k2.  Hence, 
AdvSIg(s)  >  e(s)/k2  as  required.  □ 

We  note  that  this  PEKS  can  be  viewed  as  derived  from  an  IBE  system  with  a  limited  number 
of  identities.  For  each  identity  there  is  a  pre-specified  public  key.  Such  an  IBE  system  is  implied 
in  the  work  of  Dodis  et  al.  [13].  They  propose  reducing  the  size  of  the  public-key  using  cover-free 
set  systems.  We  apply  the  same  idea  below  to  reduce  the  size  of  the  public  key  in  the  PEKS  above. 

Reducing  the  public  key  size.  The  drawback  of  the  above  scheme  is  that  the  public  key  length 
grows  linearly  with  the  total  dictionary  size.  If  we  have  an  upper-bound  on  the  total  number  of 
keyword  trapdoors  that  the  user  will  release  to  the  email  gateway  (though  we  do  not  need  to  know 
these  keywords  a-priori)  we  can  do  much  better  using  cover-free  families  [15]  and  can  allow  keyword 
dictionary  to  be  of  exponential  size.  Since  typically  a  user  will  only  allow  a  third  party  (such  as 
e-mail  server)  to  search  for  a  limited  number  of  keywords  so  that  assuming  an  upper  bound  on  the 
number  of  released  trapdoors  is  within  reason.  We  begin  by  recalling  the  definition  of  cover-free 
families. 

Definition  3.5.  Cover-free  families.  Let  d,t,k  be  positive  integers,  let  G  be  a  ground  set  of  size 
d,  and  let  F  =  {Si, . . . ,  Sk}  be  a  family  of  subsets  of  G.  We  say  that  subset  Sj  does  not  cover  Si  if 
it  holds  that  Si  %.  Sj.  We  say  that  family  F  is  t- cover  free  over  G  if  each  subset  in  F  is  not  covered 
by  the  union  oft  subsets  in  F.  Moreover,  we  say  that  a  family  of  subsets  is  (/-uniform  if  all  subsets 
in  the  family  have  size  q. 

We  will  use  the  following  fact  from  [14]. 

Lemma  3.6.  [14]  There  exists  a  deterministic  algorithm  that,  for  any  fixed  t,k,  constructs  a 
(/-uniform  t-cover  free  family  F  over  a  ground  set  of  size  d,  for  q  =  \d/At\  and  d  <  16f2(l  + 
log(fc/2)/  log  3). 

The  PEKS.  Given  the  previous  PEKS  construction  as  a  starting  point,  we  can  significantly  reduce 
the  size  of  public  file  Apub  by  allowing  user  to  re-use  individual  public  keys  for  different  keywords. 
We  associate  to  each  keyword  a  subset  of  public  keys  chosen  from  a  cover  free  family.  Let  k  be  the 
size  of  the  dictionary  E  =  {W\, . . . ,  If  A }  and  let  t  be  an  upper  bound  on  the  number  of  keyword 
trapdoors  released  to  the  mail  gateway  by  user  Alice.  Let  d,  q  satisfy  the  bounds  of  Lemma  3.6. 
The  PEKS (d,t,k,q)  construction  is  as  follows: 

•  KeyGen:  For  i  =  1  ,...,d  run  algorithm  G(s)  to  generate  a  new  public/private  key  pair 
PKi/Privi  for  the  source-indistinguishable  encryption  scheme.  The  PEKS  public  key  is  Apub  = 
{PK\, . . . ,  PKd}.  The  private  key  is  Apriv  =  {Priv i, . . . ,  Privd}-  We  will  be  using  a  (/-uniform 
t- cover  free  family  of  subsets  F  =  {Si, . . . ,  Sk}  of  {PK\, . . . ,  PKd}.  Hence,  each  Si  is  a  subset 
of  public  keys. 

•  PEKS(Apu(),  Wi):  Let  Sj  G  F  be  the  subset  associated  with  the  word  W%  G  E.  Let  Sj  = 
{PKA) , . . . .  PIfW}.  Pick  random  messages  M\ , . . . ,  Mq  G  {0, 1}S  and  let  M  =  Mi©-  •  -@Mq. 
Output  the  tuple: 

PEKS(Apu6,Wj)  =  (M,  E[PKM,Mi],  ...,  E[PK^,Mq]) 

•  Trapdoor(Aprip,  ITj):  Let  Sj  G  F  be  the  subset  associated  with  word  W2  G  E.  The  trapdoor 
for  word  Wt  is  simply  the  set  of  private  keys  that  correspond  to  the  public  keys  in  the  set  Sj. 
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•  Test(Apub,  R,TW): 

Let  Tw  =  {Priv^l\  . . . ,  Priv^}  and  let  R  =  (Af,  C\ ,  . . . ,  Cq)  be  a  PEKS.  For  i  =  1, . . . ,  q 
decrypt  each  Ci  using  private  key  Priv W  to  obtain  Afj.  Output  ‘yes’  if  M  =  M \  ©  •  •  •  0  Mq, 
and  output  ‘no’  otherwise. 

The  size  of  the  public  key  file  Apub  is  much  smaller  now:  logarithmic  in  the  size  of  the  dictionary. 
The  downside  is  that  Alice  can  only  release  t  keywords  to  the  email  gateway.  Once  t  trapdoors 
are  released  privacy  is  no  longer  guaranteed.  Also,  notice  that  the  size  of  the  PEKS  is  larger  now 
(logarithmic  in  the  dictionary  size  and  linear  in  t).  The  following  corollary  of  Theorem  3.4  shows 
that  the  resulting  PEKS  is  secure. 

Corollary  3.7.  Let  d,t,k,q  satisfy  the  bounds  of  Lemma  3.6.  The  PEKS (d,t,k,q)  scheme  above  is 
semantically  secure  under  a  chosen  keyword  attack  assuming  the  underlying  public  key  encryption 
scheme  (G,  E,  D )  is  source-indistinguishable  and  semantically  secure,  and  that  the  adversary  makes 
no  more  than  t  trapdoors  queries. 

Proof  sketch:  Let  S  =  {W\, . . .  ,Wk]  be  the  keyword  dictionary.  Suppose  we  have  a  PEKS 
attacker  A  for  which  Adv_4(s)  >  e(s).  We  build  an  attacker  B  that  breaks  the  source  indistin- 
guishability  of  ( G,E,D ). 

Algorithm  B  is  given  two  public  keys  PKq,  PI\\  and  a  pair  (Af,  C )  where  M  is  random  in  {0, 1}S 
and  C  =  PKb{M)  for  b  £  {0, 1}.  Its  goal  is  to  output  a  guess  for  b  which  it  does  by  interacting 
with  A.  Algorithm  B  generates  d  —  2  additional  public/private  keys  using  G(s).  It  creates  Apub  as 
a  list  of  all  d  public  keys  with  PKq,  PK\  embedded  in  a  random  location  in  the  list.  Let  11} ,  Wj 
be  the  words  associated  with  the  public  keys  PKq,  PK\. 

B  sends  Apub  to  A.  Algorithm  A  issues  up  to  t  trapdoor  queries.  B  responds  to  a  trapdoor 
query  for  W  £  S  as  follows:  let  S  £  F  be  the  subset  corresponding  to  the  word  W .  If  PKq  £  S 
or  PK\  £  S  algorithm  B  reports  failure  and  aborts.  Otherwise,  B  gives  A  the  set  of  private  keys 
{Privi  |  i  £  S}. 

At  some  point,  Algorithm  A  outputs  two  words  Wq,  W[  £  S  on  which  it  wishes  to  be  challenged. 
Let  Sq  ,  S\  £  F  be  the  subsets  corresponding  to  Wq,W[  respectively.  Let  £  be  the  event  that 
PKq  £  Sq  and  PK\  £  S[.  If  event  £  did  not  happen  then  B  reports  failure  and  aborts. 

We  now  know  that  PKq  £  S'0  and  PK\  £  S[.  For  j  =  0, 1  let  S'  =  {PI<f\  ...,  PK(f}.  We 

(c)  (c) 

arrange  things  so  that  PKq  =  PKq  '  and  PK\  =  PK[  for  some  random  1  <  c  <  q.  Next,  B 
picks  random  M \ , . . . ,  Afc_i,  Afc+i, . . . ,  Mq  £  {0, 1}S  and  sets  Mc  =  M.  Let  M'  =  Mi  ©  •  •  •  ©  Mq. 
Algorithm  B  defines  the  following  hybrid  tuple: 

R  =  (V,  E[PK^\Mi],  ...,  E[PK^~l\M^i],  C , 

E[Pk[c+1\mc+  i],  . . . ,  E[PK[q),Mq]^j 

It  gives  R  as  the  challenge  PEKS  to  algorithm  A.  Algorithm  A  eventually  responds  with  some 
b'  £  {0,1}  indicating  whether  R  is  PEKS(Apui),  Wq)  or  PEKS(Apu(),  W[).  Algorithm  B  outputs  b' 
as  its  guess  for  b.  One  can  show  using  a  standard  hybrid  argument  that  if  B  does  not  abort  then 
|  Pr[6  =  b'}  —  \\  >  e/ q2 .  The  probability  that  B  does  not  abort  at  a  result  of  a  trapdoor  query  is  at 
least  1  —  ( tq/d ).  The  probability  that  B  does  not  abort  as  a  result  of  the  choice  of  words  Wq,W[ 
is  at  least  ( q/d )2.  Hence,  B  does  not  abort  with  probability  at  least  1  /poly{t,q,d).  Repeatedly 
running  B  until  it  does  not  abort  shows  that  we  can  get  advantage  e/q 2  in  breaking  the  source 
indistinguishability  of  ( G ,  E,  D)  in  expected  polynomial  time  in  the  running  time  of  A.  □ 
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4  Construction  using  Jacobi  symbols 


Given  the  relation  between  Identity  Based  Encryption  and  PEKS  it  is  tempting  to  construct  a  PEKS 
from  an  IBE  system  due  to  Cocks  [3].  The  security  of  Cocks’  IBE  system  is  based  on  the  difficulty 
of  distinguishing  quadratic  residues  from  non-residues  modulo  N  =  pq  where  p  =  q  =  3(mod4). 

Unfortunately,  Galbraith  [11]  shows  that  the  Cocks  system  as  described  in  [3]  is  not  public- key 
private  in  the  sense  of  Bellare  et  al.  [1].  Therefore  it  appears  that  the  Cocks  system  cannot  be 
directly  used  to  construct  a  PEKS.  It  provides  a  good  example  that  constructing  a  PEKS  is  a  harder 
problem  than  constructing  an  IBE. 

We  briefly  explain  why  the  basic  Cocks  system  is  not  public  key  private.  Let  N  G  Z  be  a 
product  of  two  primes.  For  a  public  key  x  G  Z^r  and  a  bit  b  6  {0, 1}  define  Px ^  to  be  the  set 

Px,b  =  {r  +  -  |  rGZjv  and  (r/N)  =  (-1)6}  C  ZN 

r 

where  (r/N)  denotes  the  Jacobi  symbol  of  r  over  N.  Fix  some  b  G  {0, 1}.  To  show  that  the  system 
is  not  public  key  private  it  suffices  to  show  an  algorithm  that  given  two  distinct  public  keys  x  and  y 
in  Z n  can  distinguish  the  uniform  distribution  on  Pxy  from  the  uniform  distribution  on  Py.b-  The 
algorithm  works  as  follows  (it  is  given  as  input  x,y  G  Z^r  and  z  6  Zjy  where  z  is  either  sampled 
from  Pxfi  or  from  Pyb)' 

1.  Compute  t  =  z2  —  4x  G  Z/y. 

2.  If  the  Jacobi  symbol  ( t/N )  =  1  output  “z  G  Px,b"  ■  Otherwise  output  “z  G  Py,b  ■ 

When  z  is  sampled  from  Px ^  then  t  =  z2  —  Ax  =  (r  —  ( x/r ))2  and  hence  t  will  always  have  Jacobi 
symbol  1  over  N.  When  z  is  sampled  from  Py^  then  we  expect  t  to  have  Jacobi  symbol  1  over  N 
with  probability  about  1/2.  Therefore,  the  algorithm  has  advantage  1/2  in  correctly  identifying 
where  z  is  sampled  from.  Since  a  Cocks  ciphertext  contains  many  such  samples,  the  algorithm 
above  determines  whether  a  ciphertext  is  encrypted  under  the  public  key  x  or  the  public  key  y  with 
overwhelming  probability.  Note  there  is  no  need  to  know  the  plaintext  b. 

5  Conclusions 

We  defined  the  concept  of  a  public  key  encryption  with  keyword  search  (PEKS)  and  gave  two 
constructions.  Constructing  a  PEKS  is  related  to  Identity  Based  Encryption  (IBE),  though  PEKS 
seems  to  be  harder  to  construct.  We  showed  that  PEKS  implies  Identity  Based  Encryption,  but 
the  converse  is  currently  an  open  problem.  Our  constructions  for  PEKS  are  based  on  recent  IBE 
constructions.  We  are  able  to  prove  security  by  exploiting  extra  properties  of  these  schemes. 
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Abstract.  We  present  a  new  class  of  signature  schemes  based  on  proper¬ 
ties  of  certain  bilinear  algebraic  maps.  These  signatures  are  secure  against 
existential  forgery  under  a  chosen  message  attack  in  the  standard  model 
(without  using  the  random  oracle  model).  Security  is  based  on  the  com¬ 
putational  Difhe-Hellman  problem.  The  concrete  schemes  that  we  get  are 
the  most  efficient  provable  discrete-log  type  signature  schemes  to  date. 


1  Introduction 

Provably  secure  signature  schemes  can  be  constructed  from  the  most  basic  cryp¬ 
tographic  primitive,  one-way  functions  [NY89,Rom90].  As  is  often  the  case  with 
cryptographic  schemes  designed  from  elementary  blocks,  this  signature  scheme 
is  somewhat  impractical.  Over  the  years  several  signature  schemes  were  pro¬ 
posed  based  on  stronger  complexity  assumptions.  The  most  efficient  schemes 
provably  secure  in  the  standard  model  are  based  on  the  Strong  RSA  assump¬ 
tion  [GHR99,CS99]. 

Surprisingly,  no  scheme  based  on  any  discrete  logarithm  problem  comes  close 
to  the  efficiency  of  the  RSA-based  schemes.  We  give  a  partial  solution  to  this 
open  problem  using  bilinear  maps.  A  bilinear  map  is  a  function  e:  Go  xGi  G2 
that  is  consistent  with  group  operations  in  both  of  its  arguments,  as  described  in 
the  next  section.  Our  construction  gives  an  existentially  unforgeable  signature 
whenever  the  Computational  Diffie-Hellman  (CDH)  assumption  holds  in  Go  x  Gi , 
that  is,  no  efficient  algorithm  can  compute  ga  £  Gi  given  the  three  values 
h,  ha  £  Go,  and  g  £  Gi.  Precise  definitions  are  given  in  the  next  section. 

Our  signature  scheme  is  based  on  a  signature  authentication  tree  with  a 
large  branching  factor.  At  a  high  level,  our  construction  bares  some  resemblance 
to  the  signature  schemes  of  Dwork-Naor  [DN94]  and  Cramer-Damgard  [CD96]. 
Both  these  schemes  are  based  on  the  hardness  of  factoring  whereas  our  scheme 
is  based  on  CDH. 

We  obtain  a  concrete  signature  scheme  by  instantiating  the  bilinear  map 
with  the  modified  Weil  or  Tate  pairings.  This  is  the  only  known  provably  se¬ 
cure  signature  scheme  based  on  the  CDH  assumption  that  is  more  efficient  than 
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the  most  general  constructions  of  [CD95].  It  is  interesting  to  note  that  recently, 
Lysyanskaya  [Lys02]  constructed  a  verifiable  unpredictable  function  (VUF)  se¬ 
cure  under  the  Generalized  Diffie-Hellman  assumption  in  the  standard  model. 
Such  functions  (defined  in  [MRV99])  provide  a  special  type  of  secure  signatures 
called  unique  signatures.  This  construction  gives  an  excellent  VUF,  but  as  a  sig¬ 
nature  scheme  it  compares  poorly  with  the  construction  of  [CD95].  We  review 
other  known  signature  schemes  in  Section  4. 

Bilinear  maps  such  as  the  Weil  or  Tate  pairing  have  recently  been  used 
to  construct  a  number  of  new  cryptosystems,  including  three-party  key  ex¬ 
change  [JouOO],  identity  based  encryption  [BF01],  short  signatures  [BLS01],  cre¬ 
dential  systems  [VerOl],  hierarchical  identity  based  encryption  [HL02,GS02],  and 
others.  In  this  paper  we  show  how  bilinear  maps  can  be  used  to  construct  efficient 
signature  schemes  secure  in  the  standard  model. 

Efficient  discrete  log  based  signature  schemes  are  known  to  exist  in  the  ran¬ 
dom  oracle  model  [PS96,BLS01].  Security  in  the  random  oracle  model  does  not 
imply  security  in  the  real  world.  In  this  paper  we  only  study  signature  schemes 
secure  in  the  standard  complexity  model. 


2  Mappings  with  Algebraic  Properties 


We  consider  binary  maps  between  groups  that  are  consistent  with  the  group 
structure  of  their  arguments.  Such  binary  maps  are  called  bilinear.  Their  formal 
definition  follow. 


Definition  1  (Bilinear  map).  A  function  e:  Go  x  Gi  i— >  G2  is  bilinear  if  for 
any  four  elements  <71 ,  <72  G  Go,  H\,H2  €  Gi  the  following  holds: 

e{gi°g2,Hi)  =  e(g1,H1)oe(g2,H1)  and  e(g1,H1oH2)  =  e(g1,H1)oe(g1,H2). 

In  this  paper  we  intentionally  limit  our  scope  to  finite  cyclic  groups,  which  allows 
us  to  give  more  efficient  constructions. 

Throughout  the  paper  we  use  the  following  notation.  Small  Roman  letters 
f,g,h,...  from  the  lower  part  of  the  alphabet  denote  elements  of  the  group  Go; 
capital  Roman  letters  F,G,H, . . .  stand  for  elements  of  Gi;  elements  of  G2  are 
denoted  by  letters  from  the  end  of  the  alphabet  x,  y,  z. 

Our  constructions  are  based  on  the  Computational  Diffie  Problem  (CDH) 
defined  below.  However  to  simplify  the  exposition  we  define  the  notion  of  a  secure 
bilinear  map.  We  then  show  that  this  notion  is  equivalent  to  CDH.  Informally, 
we  say  that  a  bilinear  map  e:  Go  x  Gi  — >  G2  is  secure  if,  given  g  £  Go  and 
G,H  £  Gi,  it  is  hard  to  find  h  £  Go  such  that  e(h,  H)  =  e(g,  G).  More  precisely, 
we  define  secure  bilinear  maps  as  follows. 

Definition  2  (Secure  bilinear  map).  A  bilinear  map  e:  Go  x  Gi  i— >  G2  is 

(t,  e)-secure  if  for  all  t-time  adversaries  A 


AdvBLM^  =Pr 


e(A(g,G,H),  H 


e(g,G) 


g  Go;  G,  H 


<  £. 
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The  probability  is  taken  over  the  coin  tosses  of  the  algorithm  A  and  random 
choice  of  g ,  G,  H. 


We  given  two  simple  examples  of  bilinear  maps  that  are  believed  to  be  secure. 

-  e(-,  •):  Go  xGi  m  F*r  is  the  Weil  or  Tate  pairings  on  an  elliptic  curve  E/Fp 
and  Go,  Gi  are  distinct  subgroups  of  E[q ]  for  some  prime  q  (recall  that  E[q]  is 
the  subgroup  containing  all  point  of  order  dividing  q  on  some  elliptic  curve 
E/Fp).  For  certain  curves  E/Fp  one  can  slightly  modify  the  Weil  pairing 
(as  in  [BF01])  so  that  we  may  take  Go  =  Gi.  At  any  rate,  the  security  of 
the  bilinear  map  e(-,-)  is  equivalent  to  the  Computational  Diffie-Hellman 
assumption  (CDH)  in  Go  xGi.  Informally,  the  CDH  assumption  in  Go  x  Gi 
means  that: 

It  is  infeasible  to  find  Ga  given  random  group  elements  h,  ha  £  Go,  and 

G  £  Gi.  When  Go  =  Gi  this  is  the  standard  CDH  assumption  in  Go- 

-  Another  bilinear  map  believed  to  be  secure  is  r(v):  Z*N  x  Z i— >  1ZN 
defined  as  r(g,  H)  =  gH ,  where  N  is  a  product  of  two  primes.  This  map  is 
secure  under  the  Strong  RSA  assumption  [BP97].  Briefly,  the  Strong  RSA 
assumption  says  that  the  following  problem  is  difficult  to  solve: 

For  a  random  x  £  Zfj  find  r  >  1  and  y  £  Zf,  such  that  yr  =  x. 

We  give  a  short  argument  why  the  security  of  the  map  r(-,-)  is  reducible 
to  the  Strong  RSA  assumption.  Suppose  the  map  r(v)  is  insecure.  Then, 
given  (G,fL,  g)  it  is  feasible  to  find  an  h  £  Go  such  that  r(g,G)  =  r(h,H), 
i.e.  gG  =  hH .  This  solution  yields  (through  application  of  the  Extended 
Euclidean  algorithm)  a  z  £  T.*N  satisfying  za  =  g,  where  a  =  H/  gcd(G,  H). 

For  random  G,H  <—  Zj^  the  probability  that  a  =  1  is  negligible.  Therefore 
breaking  the  security  of  the  bilinear  map  r  amounts  to  breaking  the  Strong 
RSA  assumption.  It  is  not  known  whether  the  converse  is  true. 

Next,  we  show  that  for  finite  order  groups  a  bilinear  map  e:  Go  x  Gi  — >  G2  is 
secure  if  and  only  if  the  CDH  assumption  holds  in  Go  x  G\.  We  first  precisely 
define  the  CDH  assumption. 


Definition  3  (Computational  Diffie-Hellman  problem).  The  Computa¬ 
tional  Diffie-Hellman  problem  is  it,  e)  -hard  if  for  all  t-time  adversaries  A  we 
have 


AdvCDH^  =  Pr 


A(g,H,Ha) 


ga  |  g  G0;  H  Gi;  a 


<  £. 


Claim.  Suppose  that  Go,Gi,G2  are  cyclic  groups  of  prime  order  p.  Suppose  the 
map  e:  Go  x  Gi  — »  G2  is  non-degenerate  in  the  following  sense:  e{h,H)  ^  1  for 
some  h  £  Go  and  H  £  Gi.  Then  the  map  e  is  (t,  e)-secure  if  and  only  if  the  CDH 
problem  is  (f ,  e)-hard. 

Proof.  First,  suppose  CDH  can  be  solved  in  time  t  with  probability  at  least  e. 
We  give  an  algorithm  to  show  that  the  map  is  not  (t,  e)-secure.  Let  g  £  Go 
and  G,H  £  Gi  where  both  G,H  ^  1.  We  wish  to  find  h  £  Go  such  that 
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e(g,  G)  =  e(/i,  H).  Since  Gi  is  cyclic  of  prime  order  p  there  exists  an  a  £  Zp  such 
that  G  =  H°.  Let  h  =  ga.  Then  h  satisfies 


e(h,H)  =  e(ga,  H)  =  e(g,Ha)  =  e(g,G). 

Therefore,  h  =  ga,  which  is  the  solution  to  the  CDH  problem  (g,H,G),  is  the 
required  h.  Hence,  if  the  map  is  (t.  e)-secure  then  CDH  is  ( t ,  e)-hard. 

Conversely,  suppose  there  is  a  t-time  algorithm  that  given  random  ( g ,  G ,  H) 
outputs  h  £  Go  such  that  e(g,  G)  =  e(h,  H)  with  probability  at  least  e.  We  show 
how  to  solve  CDH.  Let  (g,  H ,  G)  be  a  random  instance  of  the  CDH  problem, 
where  H  ^  1.  Write  G  =  Ha  for  some  a  £  Z„.  Let  h  be  such  that  e(q,G)  = 
e(h,  H).  Then 

e(h,  H)  =  e(g,  G)  =  e(g,  Ha)  =  e(ga,  H) 

and  hence  e(h/ ga ,  H)  =  1.  Since  H  ^  1  it  follows  that  h  =  ga ,  since  otherwise 
the  map  e  would  be  degenerate.  Hence,  if  CDH  is  (t,  e)-hard  then  the  map  is 
(t,  e)-secure.  □ 


3  Security  for  signature  schemes 

We  recall  the  standard  definition  of  secure  signature  schemes  stated  in  terms  of 
exact  security,  in  the  spirit  of  [BR94].  This  notion  of  existential  unforgeability 
under  adaptive  chosen-message  attack  is  due  to  [GMR88]. 

A  signature  scheme  is  a  triple  of  probabilistic  algorithms:  a  key  generation 
algorithm  KeyGen,  signer  Sign  (SK,Msg),  and  verifier  Verify  (Msg,  Sig,  PK).  By 
convention,  Verify  outputs  1  if  it  accepts  the  signature  and  0  otherwise.  We  use 
the  oracle  notation,  where  AB(- ’)(■)  means  A  supplied  with  oracle  access  to  B. 

Definition  4.  A  signature  scheme  is  (t,  e,  n)-existentially  unforgeable  under 
adaptive  chosen-message  attack,  if  for  all  pairs  of  algorithms  T\,T2  running 
in  time  at  most  t 

AdvSig^  =  Pr[Verify(^2(T),PR)  =  1  | 

(. SK,PK )  «-  KeyGen(lfe);  T  ^  F?sn{SK’'\lk)\  <  e. 

T\  requests  no  more  than  n  signatures  from  Sign  and  the  message  output  by  T2 
is  different  from  the  messages  signed  by  Sign.  The  probability  is  taken  over  the 
coin  tosses  of  KeyGen.  Sign,  T\  and  iF2.  Here  ^(T)  outputs  a  message/signature 
pair. 

4  Previous  work 

The  seminal  paper  [GMR84]  formulated  a  strong  notion  of  security  for  signature 
schemes:  existential  unforgeability  under  adaptive  chosen-message  attacks.  Since 
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then  there  have  been  many  proposals  for  signature  schemes  meeting  this  notion 
of  security  based  on  different  assumptions  and  of  varying  efficiency.  Some  of 
these  results  are  summarized  in  Table  1.  With  an  exception  of  GMR,  all  schemes 
have  running  time  of  the  signing  and  verification  algorithms  proportional  to  the 
signature  length.  This  information  is  omitted  from  the  table. 


Reference 

Signature 

length 

Public  key 
length 

Max  number 
of  signatures 

Security  assumption 

[GMR84] 

OQtl) 

0(k ) 

2f 

claw-free  trapdoor  permutations 

[NY89] 

0{k?e ) 

o(k ) 

2e 

UOWHF 

[CD95] 

0(k£) 

O(k) 

2e 

one-way  homomorphism 

[DN94] 

0(k£) 

0(kn ) 

nl 

RSA  assumption 

[CD96] 

0(k£) 

0(k  +  n) 

nl 

RSA  assumption 

[GHR99],[CS99] 

0(k ) 

0(k) 

00 

Strong  RSA  assumption 

[Lys02] 

0(km) 

O(km) 

2m 

Generalized  DifRe-Hellman 

this  paper 

0(k£) 

O(kn) 

Computational  Diffie-Hellman 
(secure  bilinear  maps) 

Table  1.  Summary  of  provably  secure  signature  schemes,  k  is  the  security  parameter, 
l  is  the  depth  of  the  authentication  three,  n  is  the  branching  factor  of  the  tree,  and 
m  is  the  message  length.  The  O-notation  refers  to  asymptotics  as  a  function  of  the 
security  parameter  k. 


A  signature  scheme  may  be  based  on  the  most  general  cryptographic  assump¬ 
tion,  namely  that  one-way  functions  exist  [NY89,Rom90].  The  proof  proceeds 
via  constructing  an  authentication  tree  and  results  in  a  scheme  in  which  the 
signature  length  is  proportional  to  the  binary  logarithm  of  the  total  number  of 
messages  signed  with  the  same  public  key.  More  efficient  (in  terms  of  the  signa¬ 
ture  length)  signature  schemes  can  be  based  on  the  Strong  RSA  assumption  or 
its  variants  [CS99,GHR99].  Important  steps  in  constructing  these  schemes  were 
the  Dwork-Naor  scheme  [DN94]  later  improved  by  [CD96].  Both  schemes  use 
trees  with  a  large  branching  factor,  which  are  therefore  very  shallow. 

The  Dwork-Naor  trick  is  crucial  for  understanding  this  paper.  In  a  nutshell, 
the  trick  allows  to  increase  the  tree’s  branching  factor  without  blowing  up  the 
signature  size.  An  authentication-tree  scheme  produces  signatures  that  represent 
paths  connecting  messages  and  the  root  of  the  tree.  Messages  are  usually  placed 
in  the  very  bottom  level  of  the  tree,  though  [CD95]  puts  messages  in  the  leaves 
hanging  from  the  inner  nodes.  The  authentication  mechanism  works  inductively: 
the  root  authenticates  its  children,  they  authenticate  their  children,  and  so  on, 
down  to  the  message  authenticated  by  its  parent.  If  the  authentication  mecha¬ 
nism  allows  attaching  children  to  a  node  only  when  some  secret  information  is 
known,  then  the  adversary  cannot  forge  signatures  without  knowing  that  secret. 

[GMR84]  and  [CD95]  take  similar  approaches  in  designing  the  authentica¬ 
tion  mechanism  (hence  the  identical  asymptotic  of  their  signature  length) .  They 
concatenate  bit  representations  of  a  node’s  children  and  compute  a  value  that 
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authenticates  this  string  in  respect  to  the  node.  To  verify  a  node’s  authenticity 
we  must  know  all  siblings  of  the  node.  If  the  tree  is  binary,  the  signature  contains 
twice  as  many  nodes  as  the  the  depth  of  the  tree.  Indeed,  each  node  must  be 
accompanied  by  its  sibling. 

Since  the  signature  length  is  proportional  to  the  depth  of  the  tree,  one  may 
wonder  whether  increasing  the  tree’s  branching  factor  is  a  good  idea.  The  fol¬ 
lowing  simple  computation  shows  why  this  is  counterproductive. 

Suppose  one  wants  to  sign  N  messages.  If  the  authentication  tree  is  binary, 
its  depth  must  be  at  least  log 2  IV.  The  signature  length  is  roughly  2fclog2iV, 
where  k  is  the  security  parameter  that  accounts  for  the  nodes’  size.  When  the 
branching  factor  of  the  tree  is  increased  from  2  to  d ,  the  depth  of  the  tree  goes 
down  to  logd  N.  The  signatures,  however,  must  include  all  siblings  of  the  nodes 
on  the  authentication  path  (ancestors  of  the  message-leaf).  Thus  the  signature 
size  becomes  dk\ogdN,  which  is  actually  more  than  in  the  binary  case. 

The  improvement  achieved  by  [DN94]  is  due  to  the  way  the  sibling  nodes 
are  authenticated.  Using  a  stronger  complexity  assumption  than  in  the  GMR 
scheme,  authenticity  of  a  node  can  be  verified  given  its  parent  and  its  authenti¬ 
cation  value,  whose  size  is  independent  of  the  branching  factor.  Each  node  has 
the  authentication  value  different  from  those  of  its  siblings  and  their  authenticity 
can  be  verified  independently.  It  allows  to  increase  the  number  of  a  node’s  chil¬ 
dren  and  decrease  the  depth  of  the  tree  without  inflating  the  signature  length. 
The  public  key  size,  being  the  branching  factor  times  the  security  parameter 
and,  because  of  that,  the  main  drawback  of  [DN94],  was  reduced  in  the  Cramer- 
Damgard  scheme  [CD96].  Finally,  two  independent  methods  proposed  in  [CS99] 
and  [GHR99]  make  the  tree  flat  by  letting  the  signer  (but  not  the  adversary) 
add  branches  on  the  fly. 

We  do  not  distinguish  between  statefull  and  stateless  schemes.  All  schemes 
can  be  made  memoryless  at  the  price  of  doubling  the  tree  depth  [G0I86].  To 
do  so  [G0I86]  suggested  using  a  pseudo-random  function  (PRF)  to  generate  all 
secret  values  in  internal  nodes  of  the  authentication  tree.  The  key  for  the  PRF  is 
kept  secret  at  the  signer.  Furthermore,  instead  of  sequentially  stepping  through 
the  leaves  of  the  tree  (one  leaf  per  signature)  we  pick  a  random  leaf  for  every 
signature.  To  make  sure  the  same  leaf  is  not  chosen  at  random  for  two  different 
signatures  we  need  to  square  the  number  of  leaves  and  hence  double  the  depth 
of  the  tree. 

In  this  paper  we  implement  the  Dwork-Naor  method  using  a  secure  bilinear 
map.  Improving  the  scheme  further  in  the  direction  of  [CD96,CS99,GHR99]  is 
left  as  an  open  problem. 


5  The  new  signature  scheme 

We  present  a  signature  scheme  based  on  a  secure  bilinear  map.  An  instantiation 
of  this  construction  yields  the  most  efficient  provably  secure  scheme  based  on 
the  Computational  Diffie-Hellman  assumption  known  to  date. 

The  signature  scheme  is  designed  as  follows. 
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—  Setup  of  the  scheme.  Groups  Go  and  Gi  have  prime  order  p.  Bilinear 
map  e:  Go  x  Gi  G2  is  secure.  Hk ■  At  1— >  {0, 1}S  is  a  family  of  collision- 
resistant  hash  functions,  where  A4  is  the  message  space  (the  key  for  Hk 
is  fixed  at  random  during  key  generation  and  made  public).  The  signature 
scheme  allows  signing  of  tn  messages,  where  t  and  n  are  arbitrary  positive 
integers. 

—  Key  generation.  The  public  and  private  keys  are  created  as  follows: 

R  R 

Step  1.  Pick  Q!i, . . . ,  an  <—  Z*  and  H  <—  Gi-  Choose  a  random  key  k  for  the 
collision  resistant  hash  function  Hk ■  Compute  Hi  <—  H1^1,. . .  ,Hn  <— 

tfi/an  <=  Gi. 

Step  2.  Pick  g  Go-  Compute  y  <—  e(g,H). 

Step  3.  Pick  /?0  Zp.  Compute  x0  <—  e(g,  iJ)^0. 

Step  4.  The  public  key  is  k,  H,  Hi, . . . ,  Hn,  y  and  Xq.  The  private  key  is 

ai,...,an,@o,  and  g. 

—  Signing  algorithm.  Each  node  in  the  tree  is  authenticated  with  respect 
to  its  parent;  messages  to  be  signed  are  authenticated  with  respect  to  the 
leaves,  which  are  selected  in  sequential  order  and  never  reused.  To  sign  the  *th 
message  M  £  A4  the  signer  generates  the  itb  leaf  of  the  authentication  tree 
together  with  a  path  from  the  leaf  to  the  root.  We  denote  the  leaf  by  Xf  €  Gi 
and  denote  the  path  from  the  leaf  to  the  root  by  {xf,  it,  X(-i,i(-i,  ■  ■  ■ , 
where  Xj  is  the  if'  child  of  Xj-i  (here  ij  £  {1, . . . ,  n}).  The  leaf  and  the  nodes 
along  the  path  and  their  authentication  values  are  computed  as  follows: 
Step  1.  All  nodes  of  the  tree,  including  the  leaf  xe,  that  have  not  been 

visited  before  are  computed  as  Xj  <—  e(g,  H)P*  for  some  random  (3j  Zp. 
The  secret  j3j  is  stored  for  as  long  as  node  Xj  is  an  ancestor  of  the  current 
signing  leaf  (fy  is  discarded  immediately  after  use) .  Note  that  when  using 
stateless  signatures  [G0I86]  the  fij  are  derived  using  a  PRF  and  hence 
there  is  no  need  to  remember  their  values. 

Step  2.  The  authentication  value  of  Xj,  the  if1  child  of  Xj-i,  is  fj  <— 

ch  (/3j_i  +Hk(xj)) 

y 

Step  3.  The  authentication  value  of  Hk(M),  the  child  of  xe,  is  /  <— 

Step  4.  The  signature  on  M  is  (/,  /^,  if  ,  . . . .  fi,ii). 

—  Verification  algorithm.  To  verify  a  signature  (/,  ft,  it,  ■  •  • ,  /1,  *1)  on  a  mes¬ 
sage  M  we  reconstruct  the  nodes  Xf, ...  ,x 0  in  a  bottom-up  order  (from  leaf 
Xf  to  root  £0).  The  signature  is  accepted  if  and  only  if  £0  matches  the  root 
of  the  tree.  More  precisely,  to  verify  the  signature  the  verifier  performs  the 
following  steps: 

Step  1.  Compute  Xf  <—  e(f,  H)  ■ 

Step  2.  For  j  =  i . . .  1  compute  Xj-i  <—  e(fj,Hi:j)  ■  y~nk(xi) . 

Step  3.  The  signature  is  accepted  if  Xo  =  Xo- 

A  signature  output  by  the  signing  algorithm  passes  the  verification  test. 
Indeed,  step  1  of  the  verification  algorithm  results  in 

e(f,H)  ■  =  e(g0e+Hk<~M\  H)  ■  e{g,H)~Hk^  =  e{g0t,H)  =  xt. 
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Fig.  1.  Authentication  tree.  The  signature  on  M  is  (/,  ft,  it, . . . ,  fi,  ii). 


For  any  j  £  1 ...  £  the  result  of  computation  in  step  2  of  the  verification  algorithm 
is 


■  y~H^xo)  =  e(g<Xij(Pj-i+'Hk(xj)),Hl/<Xij)  .  e{g^H)~Hk^  = 

e(g^-1+Hk^\H)  ■  e(g-Uk^\H)  =  e{g^~\H)  =  Xj-X. 


Signature  length.  Suppose  the  user  needs  to  generate  a  billion  signatures.  Then 
taking  n  =  20  and  £  =  4  is  sufficient  (420  >  1012).  The  public  key  will  contain  20 
elements  in  Gi  and  two  elements  in  G2.  The  signature  contains  five  elements  in 
G0.  To  get  stateless  signatures  we  would  need  to  double  the  depth  so  that  each 
signature  will  contain  nine  elements  of  Go- 


Security.  We  show  that  the  signature  scheme  is  secure  against  the  most  general 
attack.  To  formalize  it  as  a  claim  we  need  to  recall  the  definition  of  collision- 
resistance  and  assume  the  existence  of  a  collision-finding  algorithm  for  e. 
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Definition  5  (Collision-resistant  function).  We  call  function  hi :  /C  x  M  >—> 

{0, 1}S  a  family  of  (t,  £)-collision-resistant  functions,  if  for  any  t-time  algorithm 
A  its  advantage  in  finding  a  collision 

AdvCR^  =  Pr \Hk{Mx)  =  hik(M2),M i  ^  M2  \  k  £  £;  ( M1,M2 )  «-  A(k)]  <  e. 

The  probability  is  taken  over  A’s  coin  tosses. 

Definition  6  (Collision- finding  algorithm).  We  say  that  an  algorithm  is 
collision-finding  for  bilinear  map  e :  Go  x  Gi  e- >  G2  if  it  outputs  a  solution  g' ,  g"  £ 
Go,  where  g',g"  ^  1,  to  the  equation 

e{g' ,G')  =  e{g"  ,G"), 

for  given  G'  ,G"  £  Gi  whenever  such  a  solution  exists. 

For  the  bilinear  maps  defined  on  elliptic  curves,  namely  the  Weil  and  Tate 
pairings,  it  is  easy  to  build  collision  finding  algorithms.  This  yields  a  concrete 
discrete-log  signature  scheme  as  described  later  in  this  section. 

Theorem  1.  The  signature  scheme  is  (f,  e/(n  +  1  ),m)-secure  against  existen¬ 
tial  forgery  against  adaptive  chosen-message  attack  under  the  following  assump¬ 
tions: 

-  e  is  a  ( t,e)-secure  bilinear  map; 

hi  is  (t,e)~ collision-resistant  function; 

-  there  is  an  efficient  collision-finding  algorithm  for  e. 

Proof.  The  proof  is  by  contradiction.  We  show  that  existence  of  an  efficient 
forger  implies  that  we  can  either  find  a  collision  in  hi  or  solve 

eid*  1)  =  e(g2,  G3) 

for  g*  given  Gi,  G3  £  Gi  and  g2  £  Go- 

To  this  end  we  set  up  the  public  key  to  help  the  simulator  in  answering  the 
adversary’s  signing  queries.  In  the  same  time  a  forgery  would  let  us  respond 
to  the  challenge  or  find  a  collision  of  the  hash  function  with  a  non-negligible 
probability. 

First,  we  set  y  <— ■  e(g2,  G3).  Second,  we  pick  random  i  £  {0, . . . ,  n}.  Consider 
two  cases. 

R 

Case  1:  i  =  0.  We  assign  H  <—  G 1,  pick  <—  Zp  for  all  j  £  1 . . .  n  and  assign 
Hj  <—  Gg^7‘.  All  internal  nodes  of  the  authentication  tree,  including  the  root  xq 
but  excluding  the  leaves,  are  computed  as  random  powers  of  e(g2,  G3).  Suppose 
x'  is  the  jth  child  of  x" ,  where  x"  =  e(g2,  G3)7.  The  authentication  value  for  x' 
is  computed  as  f  <—  11 .  It  correctly  authenticates  x'  as  the  jth  child 

of  x",  since 


e(/,,FfJ)  •  y~H (*'>  =  e{gl^H(x,)\G\hi)  ■  e(g2,G3)~n^  =  e(ff2,G3)7  =  x" 
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When  the  adversary  requests  a  signature  on  a  message  M,  the  path  (ig, 
Xg-x,  ig-x,  ■  ■  ■ ,  ii,Xo)  is  generated  and  the  authentication  values  for  all  internal 
nodes  along  the  path  are  included  in  the  signature.  The  leaf  xg  is  computed  as 
xg  <—  e(g2,Gj  ■  for  a  randomly  chosen  7  TLp.  The  authentication 

value  for  Tt(M)  is  set  to  be  /  <—  g2.  The  leaf  xg  is  authenticated  as  the  if1  child 
of  xg- 1  as  above.  This  results  in  a  valid  signature  (/,  fg,  ig,. . . ,  fi,ii). 

Case  2:  i  G  {l,...,n}.  Assign  Hi  <—  G\.  We  randomly  choose  7,71,  . .., 

7»-i> 7*+i)  ■  ■  •  ,7 n  ^P,  assign  H  <—  G\h  and  Hj  <—  G\hi ,  for  all  j  ±  i.  We 
apply  the  collision- finding  algorithm  that  returns  d\  and  d,2  satisfying 


e(dx,Gx)  =  e(d2,G3). 


The  authentication  tree  is  constructed  from  the  bottom  up.  Suppose  we 
are  given  a  set  of  siblings  zx,...,zn.  The  challenge  is  to  define  their  parent 
node  z  such  that  we  may  find  authentication  values  for  all  of  them.  Let  z  <— 
e(d2,G3)y~n(zi)  for  a  randomly  chosen  6  £  Z9.  For  all  j  €  1 . . .  n,  such  that  j  ^ 
i,  the  authentication  value  of  Zj  can  be  computed  as  fj  <—  .  df)^ . 

Indeed,  for  all  such  j 


e(fj>Hj)  ■  y~n M  =  e((^fe)-W("i)  •  ds2)^ ,G\hi)  ■  e(g2,G3)-n M  = 
e(g?M~nM  ■  ds2,G3)  ■  e(g~n^\G3)  =  e{g~H{zi)  ■  d52,G3 )  = 

e(d2,Gs3)  ■  e(g2,G3)-n ^  =  e(d2,Gs3)y-n^  =  Zj. 

Node  Zi  is  authenticated  with  /,;  <—  d\.  Indeed, 

e(fi,  Hi)  ■  y~H ^  =  e(d{,  G\)  ■  y~H =  e(ds2,  G3)  ■  y~H ™  =  z. 


It  follows  that  every  internal  node  may  be  computed  given  its  jth  child.  In 
particular,  the  root  of  the  tree,  Xo,  is  determined  by  values  on  the  path  (xg,  j, 
xg- 1,. . .  ,X\,  j),  which  can  be  efficiently  computed  by  the  randomized  algorithm 
given  above. 

When  a  signature  is  requested  by  the  adversary,  a  new  leaf  is  generated  as 
xg  <—  e(g2,Hs),  where  6  ^  Zp.  Then  the  path  to  the  root  is  computed,  which 
would  involve  generating  new  nodes  from  their  jth  children.  The  authentication 
value  for  H(M)  is  given  by  /  <—  g2+in^M\ 

We  have  shown  that  the  simulator  may  effectively  replace  the  signing  ora¬ 
cle  and  answer  the  adversary’s  queries.  The  simulated  answers  have  the  same 
distribution  as  signatures  output  by  the  real  signer. 

Solving  the  challenge.  Let  us  consider  an  algorithm  that  interacts  with  the  sign¬ 
ing  oracle  and  then  forges  a  signature  (/,  fg,  ig,.. . ,  fi,i\)  on  a  message  M.  With¬ 
out  loss  of  generality  we  may  assume  that  the  adversary  makes  tn  queries.  Denote 
the  full  authentication  tree  constructed  by  the  simulator  by  T .  The  signature  on 
M  has  the  form  of  an  authenticated  path  up  the  tree  from  a  leaf  to  the  root  xq- 
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Let  (x£,ie,X£-i,ie-i, . . .  ,ii,Xo)  be  the  path  reconstructed  from  the  signature. 
Define  x7  as  the  lowest  node  of  the  path  that  also  appears  in  T. 

We  distinguish  between  two  types  of  forgeries: 

Type  I:  j  =  l  Denote  the  message  that  was  previously  authenticated  using 
X£  by  M'  and  let  /'  be  the  authentication  value  of  7 It  follows  that 

e(f,H).y-nW  =xe, 

=xe, 

from  which  we  have 

=  e(///',  H).  (1) 

Type  II:  j  <  i.  Let  the  x'.+1  be  the  ?'*h  child  of  Xj  in  T  and  f  ■  be  its 
authentication  value.  Similarly,  there  are  two  equations 

eUi’Hij)  ■  y~n{xi+l)  =  Xj, 

eifjyHij)  ■  y-n(x'i+i>  =  Xj, 

that  imply 

yW(x,+1)-«(x'+1)  =  e(  /•  //;.  //,.  !.  (2) 

Consider  two  possibilities.  If  H{M)  =  H(M')  in  type  I  or  H{xj+i)  =  Tt(x'j+1) 
in  type  II  forgery,  then  we  find  a  collision  in  the  hash  function.  Otherwise,  we 
solved  equation  (1)  or  (2)  of  the  type 

Vd  =  e(f,H), 

for  d  and  /,  where  d  ^  0  and  H  is  one  of  H,  Hi, ... ,  Hn. 

Recall  that  y  =  e{g2,G^).  Since  the  simulation  of  the  adversary’s  view  is 
perfect,  the  probability  that  H  =  G i  is  Thus  e(/1/d,G i)  =  e{g2,G 3)  and 

f1/d  _  g*  ^  j  e  a  solution  to  the  challenge. 

Therefore  an  efficient  algorithm  for  forging  a  signature  can  be  used  to  either 
find  a  collision  in  the  hash  function  or  disprove  security  of  e.  This  completes  the 
proof  of  the  theorem.  □ 


6  Concrete  signature  scheme 

To  obtain  a  concrete  secure  signature  scheme  we  instantiate  the  bilinear  map 
e:  Go  x  Gi  ->  G2  with  a  map  for  which  there  is  an  efficient  collision  finding 
algorithm.  Let  E/Fp  be  an  elliptic  curve.  We  denote  by  E(Fpr )  the  group  of 
points  of  E  over  Fp»-.  Let  q  be  a  prime  divisor  of  |i?(Fp)|. 

When  using  a  supersingular  curve  over  Fp,p  >  3  we  can  take  Go  =  Gi  as 
the  subgroup  containing  all  points  of  order  q  in  .E(Fp).  The  group  G2  is  the 
subgroup  of  order  q  of  F*2.  The  modified  Weil  pairing  [BF01],  denoted  e,  is  a 
non-degenerate  bilinear  map  on  Go  x  Gi.  Since  the  CDH  assumption  is  believed 
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to  hold  for  the  group  Go,  we  know  by  Claim  2  that  e  is  secure  in  the  sense 
of  Definition  2.  Since  the  modified  Weil  pairing  is  symmetric  (i.e.  e(G,i?)  = 
e(H ,  G)  for  all  H,  G  £  Go)  a  collision  finding  algorithm  for  e  is  immediate:  given 
G,H  £  Gi  we  output  H,  G  £  Go  as  a  collision.  Indeed,  e(G,H)  =  e(H,G )  and 
hence  H,  G  is  a  collision  for  G,  H .  Since  e  is  secure  and  there  is  an  efficient 
collision  finder  we  obtain  the  following  corollary  to  Theorem  1: 

Corollary  1.  The  signature  scheme  of  Section  5  instantiated  with  the  modified 
Weil  pairing  e  is  existentially  unforgeable  under  a  chosen  message  attack  if  the 
CDH  assumption  holds  for  the  group  Go  =  Gi  defined  above. 

To  obtain  shorter  signatures  one  can  avoid  using  supersingular  curves  and 
instead  use  a  family  of  curves  due  to  Miyaji  et  al.  [MNT01].  Curves  E/¥p,p  >  3 
in  this  family  are  not  supersingular  and  have  the  property  that  if  q  divides 
|-E(Fp)|  then  E[q\  is  contained  in  ^(F^e).  Let  G0  be  the  subgroup  of  order  q 
in  E(¥p)  and  let  Gi  be  some  other  subgroup  of  order  q  in  E(¥pe).  The  Weil 
pairing  e  on  Go  x  Gi  is  not  degenerate.  Furthermore,  since  CDH  is  believed 
to  be  hard  on  Go  x  Gi,  we  know  by  Claim  2  that  e  is  a  secure  bilinear  map 
in  the  sense  of  Definition  2.  To  build  a  collision  finder  for  e  we  use  the  trace 
map  tr:  ff(Fpe)  — »  E( Fp).  For  almost  all  choices  of  Gi  the  map  tr  defines  an 
isomorphism  from  Gi  to  Go-  Then,  a  collision  finder  for  e  works  as  follows: 
given  ( G,H )  £  Gi  it  outputs  as  a  collision  the  pair  (tr(G),tr(H))  £  Go-  Indeed, 
one  can  verify  that  e(tr(G),IL)  =  e(tr(7L),G).  Therefore,  by  Theorem  1  our 
signature  scheme  is  secure  when  using  this  family  of  curves. 

We  note  that  the  RSA  function  r(x,  d)  =  xd  mod  N  while  being  bilinear 
does  not  satisfy  the  condition  of  Theorem  1  since  the  orders  of  groups  Go  and 
Gi  are  not  known  to  the  simulator.  Nevertheless,  the  signature  scheme  can  be 
instantiated  with  this  function,  which  would  yield  a  scheme  similar  to  the  Dwork- 
Naor  scheme. 

7  Conclusion 

We  presented  a  new  signature  scheme  secure  in  the  standard  model  (i.e.  without 
random  oracles)  using  groups  in  which  the  Computation  Diffie-Hellman  assump¬ 
tion  holds.  Our  scheme  can  be  implemented  using  any  secure  bilinear  map  (secure 
in  the  sense  of  Definition  2) .  Instantiating  our  signature  scheme  using  the  Weil 
or  Tate  pairings  gives  the  most  efficient  known  discrete-log  type  signature  secure 
without  random  oracles. 
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